Thoughts on a concurrent Squeak VM
reefedjib at yahoo.com
Sat Nov 3 00:53:53 UTC 2007
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
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?
More information about the Squeak-dev