[e-lang] CapTP in E progress report #5

[Kevin Reid]

On Aug 13, 2007, at 15:05, Mark Miller wrote:
> On 8/13/07, Kevin Reid <kpreid at mac.com> wrote:
>> I think this is not too unreasonable behavior. For one thing,  
>> attempting to preserve the unconnected ref's identity would, given  
>> non-transitive network failures, result in a disconnected ref  
>> possibly arriving as a far (non-broken) ref.
>
> If our only choices are that a disconnected ref 1) arrives  
> unconnected vs 2) that it might arrive non-broken, then I'd agree  
> that #1 is preferable to #2. I haven't thought about it much, but  
> my immediate reaction is that #2 would not be acceptable.

The third option that I think of now is that it arrives with an  
identity unique to the origin vat (the holder of the reference who  
saw it break), so passing it twice produces the same reference in the  
receiving vat. Now that I think about it, this is the 'best' that can  
possibly be done, given that the passing carries the problem along:  
that problem is (potentially) unique to that particular event-of- 
disconnection.

This would require that:

- The problem must be PassByCopy (not just pbc), or multiple passings  
would arrive with problems that are not the same. It not being so  
does no harm, but eliminates the sameness benefits.

- The primitive implementation of Ref.optSealedDispatch for  
disconnected-refs is changed to invoke the proxy handler, so that a  
disconnected ref can be recognized by the outgoing serialization.

- Upon breakage of a connection, the newly disconnected refs would be  
associated with swiss numbers, which are used to distinguish this  
particular disconnected-ref

- A new maker or descriptor-class to produce the disconnected refs in  
the receiving vat. Its arguments would be (swiss, problem) or  
possibly (originVatID, swiss, problem). If invoked in the origin vat  
with a swiss number previously assigned to an exported disconnected  
ref, it returns that ref.


This seems like a nontrivial amount of additional complexity in CapTP  
to support a small improvement. It would be useful for some kinds of  
distributed map-key usage patterns, though.

(The Ref.optSealedDispatch change might be good to do anyway, though.)

-- 
Kevin Reid                            <http://homepage.mac.com/kpreid/>