Thoughts on a concurrent Squeak VM
Andreas Raab
andreas.raab at gmx.de
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
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
More information about the Squeak-dev
mailing list
|