[e-lang] WormholeOp questions

[Kevin Reid]

On Aug 8, 2007, at 12:00, Mark Miller wrote:
> On 8/7/07, Kevin Reid <kpreid at mac.com> wrote:
>> http://www.erights.org/elib/distrib/captp/WormholeOp.html says:
>>
>>> When VatA introduces VatB to Carol, she first wormholes the
>>> unacknowledged portion of her outgoing VatA-to-VatC VatTP stream
>>> through VatB for delivery to VatC. VatB then wormholes it towards
>>> VatC before acting on further messages from VatA.
>>
>> Am I correct that this last ordering guarantee is only for messages
>> from VatA which would cause VatB to enqueue more traffic toward VatC?
>
> Yes, but this always includes the case described above. If vatA sends
> to vatB a farRef to Carol in vatC, this will cause vatB to communicate
> to vatC.

I see.

>> I ask because a premise of my CapTP design -- that CapTP messages can
>> be implemented as messages delivered to an E object -- depends on not
>> having to delay more than can be done synchronously (i.e. enqueue for
>> VatB before the end of the turn).
>
> I don't see the conflict. The suggested WormholeOp protocol is  
> fully non-blocking. I think I don't understand the question.

The "before acting on" suggested that there might be some need to  
*defer* processing of further messages from VatA.


>>> ... LookupDesc(...
>> Should this be Far3Desc? There is no LookupDesc documented on the  
>> main CapTP page.
> Yes.

Fixed.


>> Am I correct that the reason VatB being uncooperative does no harm  
>> is that VatB cannot get a reference to Carol until the A->C  
>> provideFor is delivered, thus not performing the WormholeOp  
>> results in acceptFrom either failing or succeeding after the older  
>> A->C traffic has been delivered?
>
> Yes.

I've added a paragraph describing this scenario; please edit as you  
prefer.

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