Tom <tmb at lumo.com> is widely believed to have written:

> It seems to me that #step implements a poor man's lightweight process.
I don't think I could agree with that; the objects that step are not
running concurrently but rather get sent the step message every now and
then under the control of the main Morphic process loop.
> Is there any reason for not actually using separate lightweight processes?
I think so; truly concurrent threads would need synchronisation to
handle the fact that very little of the code in the image is thread
safe. You pretty much said this yourself when referring to the need for
mailboxes etc in other threaded UIs.
It could certainly be done with work, and I encourage you to try it if
it is something you feel motivated to work on. My worry is the overhead
of all the synchronisation might add up to enough to halt the system,
not to mention the problems of deadlock, spinning and other ways of
crunching the system.

I think I can see a simple experiment you could do to begin examining
the project. Change the step mechanism to use a trivial Process
something like
[self waitOnMySemaphore. self doStepStuff] newProcess
and then the actual step method would become
self signalMySemaphore
rather than
self doStepStuff
(obviously I'm paraphrasing here)
None of the rest of the system would need to change and you should find
out quickly where synchronisaton and other problems occur. Just a
thought.

tim

-- 
Tim Rowledge, tim at sumeru.stanford.edu, http://sumeru.stanford.edu/tim
Strange OpCodes: RC: Rewind Core