Concurrent Futures

Rob Withers reefedjib at yahoo.com
Tue Oct 30 18:17:19 UTC 2007


Igor, why don't you add your ideas to http://wiki.squeak.org/squeak/6012.    . . .

----- Original Message ----
From: Igor Stasenko siguctua at gmail.com

> On 30/10/2007, Rob Withers <reefedjib at yahoo.com> wrote:
> 
> > It seems to me that you are building event-loops in the VM.  Consider
> > anObject that is sent a msg on thread 1, so he is assigned to thread 1 and
> > you start processing it with thread 1.  In the meantime, 3 msgs are sent to
> > this object on threads 2, 3, and 4.  Each message send is scheduled for
> > processing by thread 1, when it becomes available.  There is your
> > event-loop.
> >
> 
> Yes, exactly. I'm still unsure if it really needed for all objects in
> system. For instance, the true/false/nil object are just singletons
> without any internal state. Thus scheduling them into single thread of
> execution can be simply omitted.

The same goes for SmallIntegers, which while not singletons, are not mutable.  Perhaps Characters are also candidates for this.  These are PassByConstruction objects, which means they are always local.  PassByCopy is another type of PassByConstruction, where a copy is marshalled to the other side.


> The other thing which bothers me is a reflection. Should we expose a
> properties of native threads at language side (for using/showing them
> in debugger)? Or how well new contexts will deal with continuations,
> which is used in seaside..

I think each process should know which thread id it is running in.  In my model, the process stays with the thread, while in yours I am not sure.  A message to a VatRef to an object in a different Vat, would be sent asynchronously and scheduled in the other Vat for it's thread to process.

BTW, in another email you asked about how passing a ref between Vats (Islands) guaranteed that all msgs to it would go to the home Vat.  The answer is that a ref to a Vat local object, being passed as an arg to a msg send to a VatRef to an object in a different Vat, would be translated into a VatRef back to the origin Vat when the MsgSend marshalled it's arguments to the 2nd Vat.  No ref with direct memory access would ever be allowed to be passed to another Vat.


> > But the primitive may have internal state that can't be shared.
> 
> 
> I know, but i'm talking about basic primitives which used most
> frequently and operating only with object memory. Such primitives
> usually don't have any internal state, or using an interpreter state.

Ok, so from the link above, the ProtectedPrimitives would not always be protected.

> 
> All other primitives which have internal state should be reviewed.
> And at first stages we could add support for scheduling all these
> 'old' primitives into single 'main' thread. So they will work as in
> current VM not knowing that VM is actually multithreaded.

I was thinking we mutex protect them, but still allow different threads to use them.


> I'd like to hear more critics about such model :) If it proves to be
> viable and much or less easily doable (comparing to other models) then
> i could start working on it :)

Go for it!!

cheers,
Rob
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20071030/3fd16ab8/attachment.htm


More information about the Squeak-dev mailing list