Ok, here some code to illustrate what i have in mind.
There's nothing sophisticated and VM can be modified relatively easy
to support it.
We can do same for primitives and inter-image sends.

We can have a same simple struct in C to encapsulate context state, like:
struct context {
  void (fn*) (void*param) ; // function pointer
  void * param; // arbitrary parameter
  struct context * sender; // pointer to context which will receive
result and be activated after   fn done
  void * result;  // can be present to store fn result , if fn is a
function returning non void
};

On 01/11/2007, Rob Withers <reefedjib at yahoo.com> wrote:
>
> ----- Original Message -----
> From: "Igor Stasenko" <siguctua at gmail.com>
> To: "The general-purpose Squeak developers list"
> <squeak-dev at lists.squeakfoundation.org>
> Sent: Thursday, November 01, 2007 8:21 AM
> Subject: Re: Thoughts on a concurrent Squeak VM
>
>
> > On 01/11/2007, Andreas Raab <andreas.raab at gmx.de> wrote:
> >> 2) Implement the "failure mode" for calling primitives from non-primary
> >> threads and possibly implement the first few plugins that are
> >> multi-threaded (files, sockets, ffi come to mind).
> >>
> >
> > Writing a generic threading framework comes in mind.
> > A brief description:
> > - each object in system should have a way how to get it's assigned
> > thread id (and how assign it , of course).
> > - if we see, that object having assigned thread, that means, that this
> > object is 'captured' by given thread for processing, and we need to
> > schedule new messages to that thread.
> >
> > Early i proposed this approach only for smalltalk objects and their
> > active contexts, but this concept can be easily expanded to virtually
> > any objects in system (Interpreter/GC/primitives).
>
> +1.
>
> Please expose the ability for a use to do a scheduled move of an object from
> one thread to another thread.
>
>
> > You can see that with this concept we can virtually mix an interpreter
> > 'sends' with VM low-level 'sends'.
>
> Yes, indeed.
>
>
>
>


-- 
Best regards,
Igor Stasenko AKA sig.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ObjectsMT.st
Type: application/octet-stream
Size: 4404 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20071102/5971857c/ObjectsMT.obj