Richard L. Peskin wrote:
> 
> I may be wrong, but it appears that the Squeak interpreter is single
> threaded. (At least that is the impression I get from looking at interp.c,
> and observing the behaviour during a net-based "upgrade".)
That's right.
> For those of us
> interested in using Squeak in an IPC environment, this single thread
> operation can be a problem. For example, if a Squeak process calls a
> numerically intensive external process (say using a TCP/IP based
> primitive), everything is "on hold" until that external process returns.
That's only partially right. If you use TCP/IP, for example, your
Smalltalk process will be suspended while waiting on the socket for a
response, but other Smalltalk processes are free to run regardless. So
although the VM itself is single-threaded, it implements a
multi-threaded Smalltalk process model.

As others have said, this gets somewhat more complicated if you have a
function-based interface to external systems (then you need that 'thread
pool' approach or some such).
Having a Smalltalk VM that's multi-threaded within poses quite difficult
problems, really. I would not want to implement, debug and maintain such
a beast in the context of Squeak, since it would seriously complicate
the whole VM, making it much less accessible than it is now. And you get
all sorts of weird platform dependencies, as thread support is virtually
guaranteed to be different on each platform. And I'm not talking about
the various bugs and implementation limits that you would have to work
around...

Hans-Martin