On Sat, Feb 23, 2008 at 4:01 AM, Michael van der Gulik
<mikevdg at gmail.com> wrote:
>
> I disagree about it being the right approach in the long term.

The correct mid-term approach is to do what Erlang did:  Have one
image, and one OS-thread per *schedular*.  Then when new processes run
they get a particular scheduler.  All IO is non-blocking, etc.

The long term will be to remove the OS threads, as when we have 100's
of cores memory sharing simply wont be possible.

> In the short term, the Hydra VM allows the use of multiple cores without
> large changes to the core of Squeak, which is good and IMHO the right
> decision for a quick and reliable solution (for whoever Igor is doing his
> work for... Qwaq?). The disadvantage with the Hydra VM is that all
> inter-process communication needs to go through a pipe; this makes sharing
> objects and synchronising access while still getting good performance more
> difficult. I can't back up my claims yet; we'll see how Hydra VM works out.

Fine-grained locking should be considered as obsolete as manual memory
management (at least at language level.  The VM can do it internally
so long as it's hidden.  Like memory management).