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
On the initiating side, a vat will call syscall.resolve() with a type of "forward" and a value of a Promise. (or we remove the "type" from resolve() and just look at the argument: if it's a Promise, then this is a forwarding instead of a fulfill-to-object or fulfill-to-data).
Within the kernel, the simplest/laziest implementation just sets the Promise Table to state=forwarded(newpromise). All other operations that touch that promise (subscriptions, delivering messages to it) look through to the new promise instead.
When doing the resolution, we must make sure we don't create a cycle. It should probably be illegal for a vat to create a cycle (i.e. the vat gets terminated), but we should make sure it's not possible for one vat to kill another in this way.
On the receiving side, vats should probably be notified when a Promise they've heard about gets resolved/forwarded to some other promise (which they might then be told about for the first time).
The more sophisticated/clever kernel implementation would walk the clists and kernel tables and replace all references to the old promise with the new one. This would let us delete things faster. OTOH, we have to think more carefully about what the vats still know about (non-injective mappings in the clists, as two vat promise IDs now actually map to the same kernel promise).
The text was updated successfully, but these errors were encountered:
As mentioned (briefly) in https://github.com/Agoric/SwingSet/issues/88#issue-466473458 , we still need to implement the "forwarding" type of promise resolution, and figure out notification for it.
On the initiating side, a vat will call
syscall.resolve()
with a type of "forward" and a value of a Promise. (or we remove the "type" fromresolve()
and just look at the argument: if it's a Promise, then this is a forwarding instead of a fulfill-to-object or fulfill-to-data).Within the kernel, the simplest/laziest implementation just sets the Promise Table to
state=forwarded(newpromise)
. All other operations that touch that promise (subscriptions, delivering messages to it) look through to the new promise instead.When doing the resolution, we must make sure we don't create a cycle. It should probably be illegal for a vat to create a cycle (i.e. the vat gets terminated), but we should make sure it's not possible for one vat to kill another in this way.
On the receiving side, vats should probably be notified when a Promise they've heard about gets resolved/forwarded to some other promise (which they might then be told about for the first time).
The more sophisticated/clever kernel implementation would walk the clists and kernel tables and replace all references to the old promise with the new one. This would let us delete things faster. OTOH, we have to think more carefully about what the vats still know about (non-injective mappings in the clists, as two vat promise IDs now actually map to the same kernel promise).
The text was updated successfully, but these errors were encountered: