Hi Igor,

As I wait for SystemTracer to do its thing...

I've been reading Mark Miller's thesis on E, over at erights.org.  It's very 
interesting.  He is a proponent of non-shared memory event loops.  He 
describes each Vat as being a stack, a queue and a heap.  Its a stack of 
immediate calls, of the currently executing event, a queue of pending 
events, and a heap of objects this Vat controls.  On the other hand, he 
talks about a BootStrapComm (I think this is what it is called) system which 
allows Vats in the same address space to pass references back and forth, so 
E supports shared-memory event loops as well.  I thought you'd find this 
interesting.

You have yourself a queue and a stack (as you activate a pending context). 
I think of a future/promise more as a pending action that get's scheduled, 
before it has a value in its continuation.  It just so happens that the 
resolve: action for activating the continuation of a eventual message send, 
is also an eventual message send, but with no continuation of its own.

> This means that future can be simply a special kind of context, which
> activates after original send and then uses result to send new message
> for it.

That sounds right, although I am unclear on what "uses result to send new 
message for it" means.

The other thought I had was that garbage collection in squeak seems to 
happen when needed, immediately.  Things may be so dire for memory that it 
has to do or die.  This would give us a problem making it scheduled as 
another event, wouldn't it?

cheers,
Rob