-
Notifications
You must be signed in to change notification settings - Fork 212
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
provide makeMarshal and other vatPowers uniformly to all worker types #1776
Comments
This adds a new message to the vat-to-kernel protocol, `['testLog', ...args]`, to deliver the strings from the vat to the kernel. They get added to the same `c.dump().log` array that local workers can write to. This is solely for the benefit of unit tests. refs #1776 (closing the `testLog` part, but not the other vatPowers)
This adds a new message to the vat-to-kernel protocol, `['testLog', ...args]`, to deliver the strings from the vat to the kernel. They get added to the same `c.dump().log` array that local workers can write to. This is solely for the benefit of unit tests. refs #1776 (closing the `testLog` part, but not the other vatPowers)
This adds a new message to the vat-to-kernel protocol, `['testLog', ...args]`, to deliver the strings from the vat to the kernel. They get added to the same `c.dump().log` array that local workers can write to. This is solely for the benefit of unit tests. refs #1776 (closing the `testLog` part, but not the other vatPowers)
@dckc this overlaps with code you were looking at this week. Not urgent, but wanted to circle back to the notion of a (non-transcript) syscall-like worker-to-kernel message to implement |
This ought to be improved by the fixes for #2671 , although perhaps it won't go far enough. Ideally we'll have a single shared function that creates the |
All four worker types now provide I did notice that Anyways, I'm going to redefine this ticket to be about figuring out the |
docs/static-vats.md
defines the "vatPowers
" that all vats receive. That document currently lists the following:Remotable
getInterfaceOf
makeGetMeter
(static+local vats only)transformMetering
(static+local vats only)transformTildot
In addition, the code actually provides
testLog
(which appends strings to an array that unit tests can read), and I think I've seen evidence ofmakeMarshal
being passed in under certain circumstances too.However only the "local" vatManager currently receives all of these. Our other worker types don't. We need to provide uniform support for the same values everywhere.
Remotable
andgetInterfaceOf
need to be shared with the same liveslots instance that the vat uses, since they close over an internal WeakMap to recognize pass-by-reference objects. In the cases wheremakeMarshal
is provided, I think it might fall into the same category.We could probably do without
transformTildot
(it's only used for the REPL), but for consistency we should probably implement it. In non-local workers, we must add a new worker-to-kernel protocol message. It will behave like a syscall (blocking, vat waits for kernel to respond). The vat worker will send a string of source code to the kernel, and the kernel will send a string of transformed source code back. This will keep Babel out of the worker process.testLog
can be implemented with a new one-way worker-to-kernel protocol message (it just takes a single string as argument), with no response. Alternatively, we might implement it by including an array of accumulatedtestLog
strings in thedeliveryResults
message, but I'm not sure I like that approach.We got one test to fail in a more-interesting way by providing a non-functional stub for
testLog
with the following diff:The text was updated successfully, but these errors were encountered: