-
Notifications
You must be signed in to change notification settings - Fork 223
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
Labels
Comments
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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 withpostMessage
, which involves slightly more protocol than the local worker (which merely invokes adispatch
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.
The text was updated successfully, but these errors were encountered: