unify vat-worker filenames

[warner]

The packages/SwingSet/src/kernel/vatManager/ directory currently contains the following files:

deliver.js
factory.js
localVatManager.js
nodeWorker.js
nodeWorkerSupervisor.js
nodeWorkerSupervisorCJS.js
subprocessSupervisor.js
syscall.js
transcript.js
worker-subprocess-node.js

and they could do with a renaming/cleanup pass. @dckc is likely to be working here in the next week, which might be a good time to do the cleanup.

factory.js is the entry point: it exposes a function (to the kernel) to create a new vat-manager of a particular type, with some set of options. Vat-managers of all types present a common API to the kernel for delivering messages to the vats they manage.

transcript.js, deliver.js, and syscall.js are libraries used by multiple manager types.

We currently have three types of vat-managers (and XS will be a fourth):

• The oldest is the "local" type, which runs the vat in the same process (and thread) as the kernel: it is the default.
• The "Node.js Worker" type runs the vat in the same process as the kernel, but in its own thread. In the Node.js world, Worker is the facility by which new threads are created, similar to how web browsers provide ServiceWorker and WebWorker. The kernel thread uses postMessage to send deliveries to the worker thread.
• The "Node.js Subprocess" type runs the vat in a child subprocess, communicating with it via Netstring-wrapped JSON-encoded messages sent over pipes. The child subprocess runs Node.js
• The (old) "XS Subprocess" type was just like a Node.js Subprocess, except that the child ran an XS binary instead of the Node.js binary. Our new XS type does the same, but uses a different control protocol, and uses the xsnap library to spawn and communicate with the child.

Each type of vat-manager is defined in a separate file: localVatManager.js, nodeWorker.js, and worker-subprocess-node.js.

The manager types which run the worker in a child process or thread all need some code for the child to first execute, known as a "supervisor". The Node.js Subprocess type puts this in subprocessSupervisor.js. The Node.js Worker type puts it in nodeWorkerSupervisor.js, and requires an additional file named nodeWorkerSupervisorCJS.js because you cannot start a worker from an ES6 Module -format file (so nodeWorkerSupervisorCJS.js is CJS-format and loads first, and it then can import the module-format code from nodeWorkerSupervisor.js).

The new XS-via-xsnap will require several pieces of code to be eval()ed in the child process. The first will set up the SES environment (portions of the SES-shim, and code to invoke lockdown()). The second will establish the supervisor, and install a command handler that accepts requests to create new Compartments and load vat code into them. Both must be delivered as single strings (actually byte arrays). These will be created by calling rollup() on files that live in the vatManager/ directory, and sending the resulting single string in an xsnap evaluate command.

So our current files are:

type	manager/parent	worker/child	extra worker/child
local	localVatManager.js	N/A	N/A
Node.js Worker	nodeWorker.js	nodeWorkerSupervisor.js	nodeWorkerSupervisorCJS.js
Node.js Subprocess	worker-subprocess-node.js	subprocessSupervisor.js	N/A

I think the new filenames should be:

type	manager/parent	worker/child	extra worker/child
local	manager-local.js	N/A	N/A
Node.js Worker	manager-nodeworker.js	supervisor-nodeworker.js	supervisor-nodeworker-cjs.js
Node.js Subprocess	manager-subprocess-node.js	supervisor-subprocess-node.js	N/A
xsnap subprocess	manager-subprocess-xsnap.js	supervisor-subprocess-xsnap.js	lockdown-subprocess-xsnap.js

Also note that rollup takes a non-trivial amount of time, and is especially noticeable when running unit tests that create dozens of vats or kernel instances in a single program. We can improve this by building the two supervisor bundles ahead of time, and stashing them in memory until needed. Look at buildKernelBundles in src/initializeSwingset.js and examples of its use in e.g. test/test-promises.js and follow the pattern there.

[dckc]

re lockdown-subprocess-xsnap.js... that sounds a lot like xs-vat-worker/src/bootstrap.js.

Is the xs-vat-worker package supposed to go away?

[warner]

Yeah, packages/xs-vat-worker can go away. I originally thought it would export a library that was imported by a very short packages/SwingSet/src/kernel/vatManager/manager-subprocess-xsnap.js. But (as we discussed elsewhere) I think you're right, that we've sucked all the juice out of packages/xs-vat-worker and it can now be discarded.