The beginnings of SwingSet consensus mode #3450
Conversation
michaelfig
added
SwingSet
|
add "refs #2519"? |
| @@ -85,6 +85,7 @@ export function makeVatLoader(stuff) { | |||
| } | |||
|
|
|||
| const allowedDynamicOptions = [ | |||
| 'consensusMode', | |||
There was a problem hiding this comment.
We certainly want to be able to control this mode for replay purposes, but I don't think it should be controllable through the vatAdminVat facet. A vat that is under consensus mode should not be able to acquire the power to break consensus by virtue of creating a new vat that is not. So I kind of think this shouldn't be set on a vat-per-vat basis. It should exist in managerOptions, but not be permitted in allowedDynamicOptions/allowedStaticOptions.
I'm not sure what to recommend exactly. All settings that could affect the consensus-visible activity of the system ought to be "sticky" (provided to initializeKernel and stored in the DB somehow) so that the kernel/vat's behavior will be consistent from one run to the next. But this control is obviously useful to override during a specialized replay action, where you know you're breaking that state vector for the benefit of debugging something. The verb to override it should maybe be distinct from the control used to set it initially.
(we need to reorganize/rethink the large variety of options we have, and the places that can provide them.. adding an option requires touching far too many files, among other problems)
There was a problem hiding this comment.
We certainly want to be able to control this mode for replay purposes, but I don't think it should be controllable through the
vatAdminVatfacet.
Ah, I overlooked that. Thanks for pointing it out.
But this control is obviously useful to override during a specialized replay action, where you know you're breaking that state vector for the benefit of debugging something.
I think that is a clear description of what the $DEBUG environment variable is for.
| @@ -58,6 +59,8 @@ export const makeLRU = max => { | |||
| */ | |||
| export function makeVatWarehouse(kernelKeeper, vatLoader, policyOptions) { | |||
| const { | |||
| // Whether to eliminate all vat nodeterminism. | |||
| consensusMode = false, | |||
There was a problem hiding this comment.
warehousePolicy was kind of meant to define the RAM-vs-time tradeoffs of the warehouse itself, rather than to be a way to control the execution of vats.. it feels like consensusMode wants to be part of some other options object (which the VatWarehouse may need to be aware of, to instruct VatManagers how to work). I'm not sure I have a better recommendation, though.
There was a problem hiding this comment.
I created a new kernel runtime option called overrideVatManagerOptions, which does as advertised. consensusMode now lives in there, instead of in the VatWarehouse.
| 'function', | ||
| X`Invalid VatConsole wrapper value ${wrapper}`, | ||
| ); | ||
| return [level, (...args) => wrapper(backingLog, args)]; |
There was a problem hiding this comment.
Something feels funny here, why have a three-way switch here (always-enabled, never-enabled, switchable) when supervisor-subprocess-xsnap.js also has a switch? This feels like maybe we could omit the switching code here and have the supervisors manage the disabling instead.
There was a problem hiding this comment.
The identity of the console is permanently fixed in the case of snapshots, so we need this switching code to be in the same place as where the console is first defined. I could just always enable the switching code and not use the always/never modes (which you maybe consider to be premature optimisation).
There was a problem hiding this comment.
yeah, I think I prefer the simplicity of having one mode, over the nominal performance improvement of sometimes omitting the switch
michaelfig
force-pushed
the
mfig-consensus-mode
branch
from
1ec304d to
3943498
Compare
michaelfig
force-pushed
the
mfig-consensus-mode
branch
from
3943498 to
8d5d0ff
Compare
This currently just disables `console.*` for vat users. We hope it will eventually be even stricter, but not yet.
michaelfig
force-pushed
the
mfig-consensus-mode
branch
from
8d5d0ff to
dc0839b
Compare
Refs #2519
This PR plumbs through a
consensusModekernel option that, when true, tries to eliminate observable nondeterminism from the perspective of user code in vats. For this first cut, that means that console logging is stubbed out as close to the vat code as possible.Consensus mode is the default when running
ag-chain-cosmoswithout setting$DEBUG. It is a dynamic setting, so to get debugging information, you can take an existing initdir and runDEBUG=agoric ag-chain-cosmos startto reenable debug output. Note that this may result in writing nondeterministic effects to disk, so be sure to take a copy of the initdir so that you can continue the original in consensus mode.To facilitate debugging,
ag-solodoes not use consensus mode, nor does its embedded sim-chain (which is also solo, not quorum nor genuine chain).