Thoughts on a concurrent Squeak VM

Andreas Raab andreas.raab at
Thu Nov 1 06:28:14 UTC 2007

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 

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.

   - Andreas

More information about the Squeak-dev mailing list