Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

add thread-based Vat Worker #1384

Closed
warner opened this issue Aug 7, 2020 · 0 comments
Closed

add thread-based Vat Worker #1384

warner opened this issue Aug 7, 2020 · 0 comments
Assignees
Labels
enhancement New feature or request SwingSet package: SwingSet

Comments

@warner
Copy link
Member

warner commented Aug 7, 2020

What is the Problem Being Solved?

As part of #1127, we're starting to add new worker types to Swingset. Currently, the only type we support runs the vat in the main thread, confined to a Compartment but sharing the promise queue.

The next (baby) step is to add a worker which runs in the same process as the kernel, but in a separate thread (using the Node.js Worker feature). This doesn't buy us very much, but it starts to tease out the protocol between the kernel-side VatManager, and the whereever-side VatWorker. The manager must serialize the Delivery into data, and send it to the other thread with postMessage, which involves slightly more protocol than the local worker (which merely invokes a dispatch method on the worker).

The next step after this one will be #1374, which moves the VatWorker into a subprocess, and uses pipes instead of postMessage (and netstring/JSON instead of structured clone).

The third step will be #1299, which uses the same protocol but the subprocess is running XS instead of Node.js.

@warner warner added enhancement New feature or request SwingSet package: SwingSet labels Aug 7, 2020
@warner warner self-assigned this Aug 7, 2020
warner added a commit that referenced this issue Aug 7, 2020
This adds a per-vat option to run the vat code in a separate thread, sharing
the process with the main (kernel) thread, sending VatDelivery and VatSyscall
objects over the postMessage channel. This isn't particularly useful by
itself, but it establishes the protocol for running vats in a
separate *process*, possibly written in a different language or using a
different JS engine (like XS, in #1299).

This 'nodeWorker' managertype has several limitations. The shallow ones are:

* vatPowers is missing transformTildot, which shouldn't be hard to add
* vatPowers.testLog is missing, only used for unit tests so we can probably
live without it
* vatPowers is missing makeGetMeter/transformMetering (and will probably
never get them, since they're only used for within-vat metering and we're
trying to get rid of that)
* metering is not implemented at all
* delivery transcripts (and replay) are not yet implemented

Metering shouldn't be too hard to add, although we'll probably make it an
option, to avoid paying the instrumented-globals penalty when we aren't using
it. We also need to add proper control over vat termination (via meter
exhaustion or manually).

The deeper limitation is that nodeWorkers cannot block to wait for a
syscall (like `callNow`), so they cannot invoke devices.

refs #1127
closes #1384
warner added a commit that referenced this issue Aug 7, 2020
This adds a per-vat option to run the vat code in a separate thread, sharing
the process with the main (kernel) thread, sending VatDelivery and VatSyscall
objects over the postMessage channel. This isn't particularly useful by
itself, but it establishes the protocol for running vats in a
separate *process*, possibly written in a different language or using a
different JS engine (like XS, in #1299).

This 'nodeWorker' managertype has several limitations. The shallow ones are:

* vatPowers is missing transformTildot, which shouldn't be hard to add
* vatPowers.testLog is missing, only used for unit tests so we can probably
live without it
* vatPowers is missing makeGetMeter/transformMetering (and will probably
never get them, since they're only used for within-vat metering and we're
trying to get rid of that)
* metering is not implemented at all
* delivery transcripts (and replay) are not yet implemented

Metering shouldn't be too hard to add, although we'll probably make it an
option, to avoid paying the instrumented-globals penalty when we aren't using
it. We also need to add proper control over vat termination (via meter
exhaustion or manually).

The deeper limitation is that nodeWorkers cannot block to wait for a
syscall (like `callNow`), so they cannot invoke devices.

refs #1127
closes #1384
@warner warner closed this as completed in 61615a2 Aug 7, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request SwingSet package: SwingSet
Projects
None yet
Development

No branches or pull requests

1 participant