You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In order to grant priority execution to the elements supporting the economy (#4318), we need a way for the appropriate vats (static, dynamic and device) to be running with a higher priority based on the design in #3465.
It's currently assumed that external economy messages would funnel into SwingSet through devices instead of the regular comms / vattp system.
Description of the Design
It's easier to reason about priorities if that property is set at vat creation and doesn't change over the life of the vat.
Static vats should all have a built-in priority:
We believe comms vat can run at low priority. If we ever need some comms handled messages to be processed at higher priority, one approach may be to run 2 comms vat, one at each priority.
If comms vat can run a a single low priority, vattp can similarly run at low priority. However if some comms messages need to be processed at high priority, vattp will need to run at least as high as the higher comms priority. We could also imagine vattp running at a highest priority to make sure there is no contention with other vat queues.
timer will likely need to be split in low priority and high priority versions depending on who the consumer is. A single high priority timer vat may also work.
vatAdmin should run at high priority, and extended to accept a priority option when creating a new vat.
We may want to control who has the authority to create a high priority vat by only exposing an attenuated vatAdminSvc to elements that don't need it. In particular it's possible that bootstrap would use an un-attenuated vat admin service to implement its loadVat, but that the vatAdminSvc it delegates to zoe would be an attenuated version so that user contract can never be started at high priority.
Security Considerations
The authority to create high priority vat is kept closely making it impossible for non economy elements to run at a higher priority.
Test Plan
Verify that bootstrap creates all vats at the expected priority.
The text was updated successfully, but these errors were encountered:
What is the Problem Being Solved?
In order to grant priority execution to the elements supporting the economy (#4318), we need a way for the appropriate vats (static, dynamic and device) to be running with a higher priority based on the design in #3465.
It's currently assumed that external economy messages would funnel into SwingSet through devices instead of the regular comms / vattp system.
Description of the Design
It's easier to reason about priorities if that property is set at vat creation and doesn't change over the life of the vat.
Static vats should all have a built-in priority:
comms
vat can run at low priority. If we ever need some comms handled messages to be processed at higher priority, one approach may be to run 2 comms vat, one at each priority.comms
vat can run a a single low priority,vattp
can similarly run at low priority. However if some comms messages need to be processed at high priority,vattp
will need to run at least as high as the higher comms priority. We could also imaginevattp
running at a highest priority to make sure there is no contention with other vat queues.timer
will likely need to be split in low priority and high priority versions depending on who the consumer is. A single high priority timer vat may also work.vatAdmin
should run at high priority, and extended to accept a priority option when creating a new vat.We may want to control who has the authority to create a high priority vat by only exposing an attenuated
vatAdminSvc
to elements that don't need it. In particular it's possible that bootstrap would use an un-attenuated vat admin service to implement itsloadVat
, but that thevatAdminSvc
it delegates to zoe would be an attenuated version so that user contract can never be started at high priority.Security Considerations
The authority to create high priority vat is kept closely making it impossible for non economy elements to run at a higher priority.
Test Plan
Verify that bootstrap creates all vats at the expected priority.
The text was updated successfully, but these errors were encountered: