[Help-smalltalk] multithreaded GST

[Paolo Bonzini]

I remember having discussed the issue in the past with Dragomir. Don't
recall if it was on the mailing list or in private e-mail though.

The changes required to get full multithreading are non-trivial because
the VM is not reentrant.  Once you made it so, almost anything should come
along with the exception of garbage collection -- which can be made
incremental (with all the complications of write barriers) or could block
the other Smalltalk VMs. If you do the work and have no serious
performance degradation, I will be happy to merge the code -- even more
now that the VM code is almost frozen (with async I/O in place and the JIT
almost there) -- but I won't start it and, to be honest, don't encourage
you.

The real question is, do we really want that?

We have Smalltalk Processes that provide fully preemptive support for
threads (not round-robin, but it would not be hard at all), only they do
not scale to multiple processors; but do we target those monster
workstations?  For multiprocessor server applications, one could write a
VM-instance pooling mechanism; it is typical however that a server (or
other event-driven application) processes multiple requests in parallel
and resolves them with a short CPU burst, and this is done nicely with a
non-scalable solution.

For very special occasions (like your SDL layer and probably GTK+
bindings, as I outlined) threads would be needed, but the need for them is
completely enclosed in the C module.  Something that could really help in
this case would be a *serializable call-in* facility, by which one could
asynchronously start a call-in which would then be performed ASAP.  This
would fit the GTK+ needs and probably yours too.


By the way, #returnFromSnapshot is correct; look at tcp/init.st or at
Blox class>>#update: (in blox/tk/BloxBasic.st). Just replace the last two
lines of blox/tk/Blox.st with

   ObjectMemory addDependent: Blox.
   Blox update: #returnFromSnapshot.

The idea is, #returnFromSnapshot is called upon initialization of an
image, but 1st-time initialization is the same so we can trigger #update:
manually (we did the same when we called Blox onStartup just after having
registered it as an init block).

-- 
|_  _  _  ___
|_)(_)| )  ,'
--------- '-._.