prototype XS-based VatWorker process #1407
Conversation
|
re "SwingSet unit tests will skip if the xs-vat-worker is missing.":
|
really? Wouldn't that render |
eh, good point. The main value of conventional-commits is to inform the correct version bump to make on the next release (breaking changes, so the major version should be bumped? new features, so the minor version should be bumped?). So there's not a lot of practical value to annotating the brand new package. For the existing package (swingset), where we're adding a new feature (the new kind of worker), we should probably label at least one of those commits with Conventional-commits aren't required, no. I'm in the habit of making my commits appease that CI check (maybe just out of embarrassment), but it's not gating the merge. |
|
BTW once the comments above are addressed, we can land this, and then add the CI run that exercises it in a later PR. |
I like this approach. Just use the tags that you understand.
I'd prefer not to reverse-engineer the release process, but to actually use the semantics that conventional-commits are supposed to have. Only use "chore" for things that are strictly mechanical changes that aren't "fix"es or "refactor"s.
heh. I find it more embarrassing to use "chore" where it's not correct. 😉 Right, they're only warned upon a PR branch, they won't fail for CI on the master branch itself. |
dckc
force-pushed
the
vatworker-1299
branch
6 times, most recently
from
591fefb
to
d3baca7
Compare
dckc
force-pushed
the
vatworker-1299
branch
3 times, most recently
from
b8688a9
to
c176c23
Compare
vatWorker runs a vat in its own process. We have drivers for both node and xs, though only the node driver is working as of this commit. We also have a kernelSimulator that takes a vat transcript (as from swingset-runner/bin/kerneldump) and simulates a swingset kernel vat manager. Earlier vatWorker work was done in a gist: https://gist.github.com/dckc/f8e0b5d838079a994784d599c282cce7 This commit is based on: 2020-07-16 b17fae8 thru 2020-08-02 a32f30e simple transcript runs as integration test The xs driver was working, to some extent, in: 2020-08-01 5b80235 agoric-sdk catch-up See also Agoric#1299
- tools/findmods.js uses npm tools to walk source tree and build
compartmap with endo-style inter-package import info
plus intra-package info
- for now, we check in the generated compartmap.json
- compartmap.json also includes a "modules" key, which is
used by reference from the XS manifest.json
- start-xs sets up SES compartments with harden etc.
- note harden SES issue 104
- src/endo-load.js does endo-style compartment-per-package
loading
solve xs compartmap constraints:
- remove .js from "modules" section of xs manifest
- remove .js when building compartment map from endo manifest
Note as of Jun 5 62c7f1e xs's Compartment constructor needed tweaking,
but no longer as of Aug 12 4842c4.
catching up with agoric-sdk's use of promise-kit in place of produce-promise eliminated a large swath of dependent code. SIGSEGV came from some interaction of Compartments and @agoric/make-hardener ?
- add moddable SDK git submodule - makefile stanza to document some git submodule usage - avoid much of x11 for moddable by using only libgio, not all of libgtk - ignore xs build dir - makefile stanza to document compartmap rebuilding
If any vats are configured to use it, but xs-vat-worker does not have
an executable to offer, swingset will throw an error. (IOU a test?)
- Swingset package depends on xs-vat-worker
- ISSUE: cycle. factor out liveslots?
- add startXsWorker kernel endowment,
which is undefined unless binary is built
- parameterize execPath, args in startSubprocessWorker()
(mantain previous defaults)
- xs-vat-worker: adopt array style protocol from SwingSet (WIP)
- based on subprocessSupervisor.js
copied SwingSet/src/kernel/vatManager/subprocessSupervisor.js
wholesale; applied ocap discipline to module-level mutable state;
adapted IO interface. Compare:
Initially it would hang after the first 2 syscalls of the first
deliver:
- [ 'subscribe', 'p-60' ]
- [ 'subscribe', 'p-61' ]
Then I fixed handle() to return a promise in all cases to be sure to
finish delivery before next blocking read.
startSubprocessWorker was a capability provided to the kernel; adding an execPath argument gave the kernel the ability to launch arbitrary executables, which is well beyond the least authority it needs. Instead, provide startSubprocessWorkerNode and startSubprocessWorkerXS powers, each of which can launch a specific executable. ack: warner
- prune spurious tap-spec dep
needs
rebase andthe CI step below, but I would like to start getting feedback from @warner @michaelfig etc.ref #1299 (comment)
xs-vat-workeragoric-labs/moddabletree via git submoduleyarn build-something(i.e.build:xs-lin) command that:xs-vat-workerexecutable, which ...xs-vat-workerexecutable (orundefinedif it doesn't exist yet, becauseyarn build:xs-linwasn't run)require.resolve, the pathname is generated at build time; using a post-install script in the not-built case, or byxs-lin.mkby way ofyarn build:xs-linxs-vat-workerexecutable and running the messages-over-pipes protocol. nope; just re-usedSwingSet/src/spawnSubprocessWorker.jscode with slight modification to parameterize executable and argsmanagerType, maybe namedxs-worker. If any vats are configured to use it, butxs-vat-workerdoes not have an executable to offer, swingset will throw an error.skipif the xs-vat-worker is missing.yarn build-somethingfirst, to get coverage of the XS worker.dependon xs-vat-worker (for the library that spawns the worker executable), but xs-vat-worker willdependon theliveSlots.jsthat lives in swingset.