[e-lang] WormholeOp questions
kpreid at mac.com
Wed Aug 8 12:58:36 EDT 2007
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 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.
>> 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?
I've added a paragraph describing this scenario; please edit as you
Kevin Reid <http://homepage.mac.com/kpreid/>
More information about the e-lang