[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Help-smalltalk] multithreaded GST

From: Paolo Bonzini
Subject: [Help-smalltalk] multithreaded GST
Date: Thu, 17 May 2001 14:15:52 +0200 (CEST)

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

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/ or at
Blox class>>#update: (in blox/tk/ Just replace the last two
lines of blox/tk/ 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).

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]