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