Repository navigation
Sandbox background process architecture #116337
Description
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
MessagePortsupport 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)
Reacted by Alexandru Dima
Activity
Tyriar commentedon Feb 10, 2021
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 commentedon Feb 11, 2021
Daniel Imms (@Tyriar) once we let the shared process be the parent of the
pty-hostwe 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
bpasero commentedon Feb 17, 2021
After discussion in the Electron sync yesterday, here is a revised diagram given Robo (@deepak1556) feedback that the new process architecture will not provide
MessagePortsupport 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:bpasero commentedon Aug 25, 2021
Merged into #92164.