Sandbox background process architecture

[bpasero]

From discussion today in standup here are suggestions for the sandbox architecture:

• leverage the existing shared process as much as possible (make it robust, start fast and have logging for crashes)
• keep main process usage as little as possible
• aggressively move things over to shared process (e.g. logger, sqlite?)
• investigate into turning the shared process into a lightweight node.js process with MessagePort support and access to Electron's proxy solution for network requests (if we cannot get proxy support here, we could think about doing ad-hoc hidden windows for network requests as a workaround)

[Tyriar]

Won't this delay terminal creation for several seconds after start up? That was the main reason for keeping this out of Shared Process. Is this temporary based on whether we can make it node or when we get message port support would be move it to be a child of main?

[bpasero]

@Tyriar once we let the shared process be the parent of the pty-host we will no longer delay startup. This can easily be controlled here:

vscode/src/vs/code/electron-main/app.ts

Lines 458 to 462 in e371fae

	this.lifecycleMainService.when(LifecycleMainPhase.AfterWindowOpen).then(() => {
	this._register(new RunOnceScheduler(async () => {
	sharedProcess.spawn(await resolveShellEnv(this.logService, this.environmentService.args, process.env));
	}, 3000)).schedule();
	});

[bpasero]

After discussion in the Electron sync yesterday, here is a revised diagram given @deepak1556 feedback that the new process architecture will not provide MessagePort support for child processes spawned from the shared process. That means, all communication from the window will have to go through the shared process and then into the child processes: