/ elib / equality

Argument Passing Rules

Vat Independent Semantics

Implicit in the following rules are that all transformations of arguments and return results must be consistent with both capability rules and E's partial ordering constraints.

• Calls don't fork: In any immediate message pass (ie, synchronous: call, success, failure, escape) the arguments transmitted are the arguments received, and the return results passed are the return results received.

• Sends make Promises: In an eventual-send, the return result always starts as a Promise for the outcome.

• Args stay Resolved: In any message pass, transmitted Resolved arguments are always received as Resolved (but due to the Lost Resolution bug, in current E implementations it may be received as a Promise instead).

• Args stay Settled: In any message pass, whether immediate or eventual (ie, asynchronous: sendOnly, pipelined-send), transmitted Settled arguments are always received as Settled arguments.

• PassByCopy args stay Near: In any message pass, transmitted Near references to PassByCopy objects are always received as Near references to the identical objects. If the message is sent between vats, this means the PassByCopy arguments must be copied by the time the message is delivered.

  Putting the above two rules together, PassByCopy hashtables can be successfully passed by copy, because the hashtable insists its keys must be Settled, and so these keys will also arrive as Settled and designating the same objects.

• PBC args stay Near: In any message pass, transmitted Near references to a PassByConstruction object are always received as Near references to a Presence of the same object. If the message is sent between vats, this means the remote presence of the PassByConstruction argument must be constructed by the time the message is delivered. (The above PassByCopy rule can be seen as a special case of this one.)

• Once Broken always Broken: In any message pass, transmitted Broken references are always received as Broken.

Vat-based Rules

But first some terminology. To a settled reference, the vat hosting the object it designates is "home". If the reference is in the same vat as the object it designates, it is "at home". A Near reference is always "at home". A PassByProxy object is hosted by one vat, so all references to the same PassByProxy object have the same home. The vat-based argument passing rules for inter-vat messages may now be defined relative to the transmitting vat, the receiving vat, and the argument's home vat.

• Leaving home: (When Carol lives in Alice's vat.) A transmitted Near reference to a PassByProxy object will arrive as a Far reference to the same object.

• Going home: (When Carol lives in Bob's vat.) A Far reference transmitted as an argument in a message sent towards the reference's home arrives as a Near reference.

• Travelling: (When Alice, Bob, and Carol are in three separate vats.) A Far references transmitted as an argument to a third vat must be received as a Far reference (but due to the Lost Resolution bug, in current E implementations it will arrive as a Promise instead).

Known Implementation Bug:
Lost Resolution

In current implementations of E, a transmitted Far reference to Carol, sent by Alice to Bob, when Alice Bob and Carol reside in three separate vats, will be received instead as a promise for Carol that will eventually resolve into a Far reference to Carol. As a result, if Alice sends Bob a hashtable containing the reference to Carol as a key, the hashtable will fail to unserialize in Bob's vat. Although we know how to fix this problem, we may not fix it quickly due to other matters being higher priority. If you run into this and need it fixed now, please let us know so we can consider reprioritizing it, and can help you figure out how to work around this problem in the meantime.