Thoughts on a concurrent Squeak VM

Igor Stasenko siguctua at gmail.com
Sat Nov 3 01:42:20 UTC 2007


On 03/11/2007, Rob Withers <reefedjib at yahoo.com> wrote:
> 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.
>
I found another thing, which may be interesting:
http://www.stackless.com/


> 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.
>
i meant that future send needs a receiver to send message. so when it
activates, it means that receiver(result) is now known and thus, a
message send can be performed.

> 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?
>

What makes you think that futures will die upon GC?
For working properly, a reference to the future are placed as 'sender
context' in context of our interest. So, when such context will done
working and return result, a sender context will be activated  - which
is our future message send.

I'm personally much more worrying about non-local returns.

If we suppose that we built a chain of future message sends in:

object future message1 message2 message3 ... messageN.

then if an error occurs in message1 (or there is non-local return), it
means that all chain of futures, which awaits for activation (message2
... messageN) should be thrown overboard.
It seems building long chains of futures is impractical.

Of course, in this case its better ask developer, why he uses futures
with methods which can do non-local returns. :)

> cheers,
> Rob
>


-- 
Best regards,
Igor Stasenko AKA sig.



More information about the Squeak-dev mailing list