add VatWorker for local threads (Node.js "Worker") #1366
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
warner
force-pushed
the
1299-node-vatworker
branch
2 times, most recently
from
f87e167
to
738b875
Compare
warner
force-pushed
the
1299-node-vatworker
branch
from
738b875
to
bc6943d
Compare
This was referenced Aug 5, 2020
warner
force-pushed
the
1299-node-vatworker
branch
from
bc6943d
to
0fa6e52
Compare
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). 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 replaying one) is 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 Remaining design issues: * I'm not yet sure how the new manager should be organized, or where it should be located. * the 'local' vatManager can probably be refactored to share more code with the new 'nodeWorker' type The controller/kernel acquired a new `shutdown()` method, to use at the end of unit tests that create `nodeWorker` -style workers. Without `shutdown()`, the worker thread would keep the process from ever exiting. The process of creating vatManagers was refactored into a single vatManagerFactory(vatID, options). Some options were added, and others fixed: managerType, enableSetup, enableInternalMetering. refs #1299
warner
force-pushed
the
1299-node-vatworker
branch
from
0fa6e52
to
0b1dbf2
Compare
|
closing this one to use a different branch |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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).
This 'nodeWorker' managertype has several limitations. The shallow ones are:
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 devicesRemaining design issues:
The controller/kernel acquired a new
shutdown()method, to use at the end of unit tests that createnodeWorker-style workers. Withoutshutdown(), the worker thread would keep the process from ever exiting.refs #1299
CC @dckc