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