Igor Stasenko wrote:
> Or as i proposed in earlier posts, the other way could be to schedule
> all primitive calls, which currently don't support multi-threading to
> single 'main' thread.

I thought about this a little more today and decided this is indeed the 
better way to go. It preserves all the semantics that currently exist in 
Squeak with regards of running in the UI thread etc. It is also trivial 
to implement since we'll need some sort of thread identifier per VM 
instance so the test can be done without any additional synchronization 
overhead.

So the (updated) steps to the multi-threaded VM would then be:

1) Objectify the Interpreter by making the code generator generate the 
appropriate code.

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).

And then, either:

3a) For message passing concurrency: Implement a "load image" primitive 
which allows loading and running another image in parallel.

3b) For shared state concurrency: Implement allocation and GC sync points.

Any interest in actually doing this? I think I might even be able to 
find some funding for a project like this if someone has a bit of spare 
time to work on it. If you are interested, let me know off-list.

Cheers,
   - Andreas