[Squeak-e] Presentation on CapTP for the OMG

[Mark S. Miller]

[cross-posted to e-lang and squeak-e]

Last January 27, Marc Stiegler and I did a presentation on CapTP for the 
OMG. The presentation is available from the OMG website at 
http://www.omg.org/cgi-bin/doc?mars/2003-01-13 or from erights.org at 
http://www.erights.org/talks/captp4omg/index.html .

Most of talk was spent trying to explain why distributed cryptographic 
capabilities are the right way to do secure distributed objects. I'd say 
this part went rather well. We even got some enthusiastic discussion of how 
the OMG might consider a Corba with cryptographic capabilities *instead* of 
Corba's current security. I was surprised at how plausible it seemed that 
this might really happen, but I have no idea what the actual politics might be.

Unfortunately, but not surprisingly, we spent the entire time on the 
security aspects of CapTP and none on the concurrency control. In preparing 
the talk, I was quite happy when I drew 
http://www.erights.org/talks/captp4omg/captp4omg/sld019.htm to explain the 
concurrency control, though I never got that far in the talk. It's nicely 
complementary to the earlier slide 
http://www.erights.org/talks/captp4omg/captp4omg/sld012.htm , from the Ode, 
which I used to explain CapTP's security.


So here's an attempt at a compact explanation of the distributed event loop 
part of E's concurrency control using this one slide. It doesn't say 
anything I haven't said elsewhere, but I do think it makes the picture as a 
whole clearer.


This shows each vat as having an L-shaped data structure recording 
what remaining computations still need doing in that vat. The green blocks 
are stack frames, and the vertical tower of green blocks is the stack. As is 
traditional, the stack is shown upside down, with the top-of-stack at the 
bottom. The purple blocks are pending deliveries -- a record of the need to 
deliver a given message to a given receiver. The horizontal row of purple 
blocks is the pending delivery queue, ie, the event queue.

Computation in each vat proceeds only at its current top-of-stack. 

An immediate call (".") pushes a new green block to the top of stack. Since 
"." can only be performed on a NEAR (intra-vat) reference, the green block 
gets added to the stack of the calling vat.

An eventual send ("<-") enqueues a new purple block to the back of the event 
queue of the vat hosting the receiver.

We see that Alice is currently executing in VatA, since VatA's top-of-stack 
points at her as receiver. In step (1), Alice executes "bob <- foo(carol)".
In step (2) we see the result -- a record of the need to deliver 
"foo(carol)" to Bob is enqueued on VatB's queue, since Bob resides in VatB.

Unshown is step (3), when computation in VatB advances till this record is 
at the front of the queue, whereupon it becomes the initial stack frame of a 
new stack, at which point Bob actually receives the message.


The remaining major concepts of E's concurrency control are promises and 
pipelining, for which I use the graphic y'all have already seen 
http://www.erights.org/talks/captp4omg/captp4omg/sld020.htm (thanks 
Darius!). And the whole when/catch, __whenMoreResolved thing, which 
currently has no pictures but needs them.


----------------------------------------
Text by me above is hereby placed in the public domain

        Cheers,
        --MarkM