Making ScriptAnalyzer multiple runspace friendly?

[JustinGrote]

CC @bergmeister
I notice that ScriptAnalyzer sets a process wide singleton instance

PSScriptAnalyzer/Engine/ScriptAnalyzer.cs

Lines 58 to 76 in 78ee946

	#region Singleton
	private static object syncRoot = new Object();
	private static ScriptAnalyzer instance;
	public static ScriptAnalyzer Instance
	{
	get
	{
	if (instance == null)
	{
	lock (syncRoot)
	{
	if (instance == null)
	instance = new ScriptAnalyzer();
	}
	}
	return instance;
	}
	}

Is there a specific reason for this? Are there portions of the analysis process that are not thread safe?

It would really help tools like PSES if we could run analysis on multiple files simultaneously, preferably via the powershell interface and a runspace pool so we could keep a "loose" coupling and not need to add a reference to the assembly for the .NET methods.

[bergmeister]

@JustinGrote
Whilst this code predates my time, let me give my view of what I think is going on:
When analysing (i.e. not formatting), almost all rules are run in parallel and they access members of this singleton such as for example the commandInfoCache (this predates my time as well). This cache exists because a handful of rules need to access command details for which they need to run Get-Command, which is very expensive in CPU and time consuming. Because of the various locks around the member access, PSSA itself is thread safe and we've improved at least those locks for better performance. However, what I've observed from many years of various reports, is that PowerShell itself is not thread safe and sometimes PSSA can crash out because of that and it's when those commands are issued (either very slow or fast CPU can increase likelihood).
If PSSA itself analysed files in parallel (and make -Path parameter accept array to let users use it?) then I wonder whether this would make this worse but other than that it should work but might be complex to refactor.
But you could issue separate Invoke-ScriptAnalyzer calls for each file and I don't think it would be an issue because they will likely have a small overlap of commands and therefore wouldn't race/compete each other or have a worse negative effect, you just pay for more cmdlet parsing/initalisation effort. At the beginning, there is also some legacy code around variable analysis but this is done on a per file basis so wouldn't be an issue either.