Stephan,

> Okay, the system should work as follows:
> 
> Variant 1. At least one OS thread is responsible to run the 
> interpreter.  The interpreter can run multiple squeak 
> processes.  A squeak process waiting in a semaphore may not
> use up any processing time.  An interpreter which has no
> running squeak processes, goes into a wait on an OS semaphore. 

This is effectively what happens (at least on Windows). All asynchronous
operations (such as sound, async file I/O, sockets) run in separate threads.
I haven't gotten around to make the UI process into a separate thread but
except from this you are describing exactly what happens. The interpreter
goes to sleep in ioRelinquishProcessor, waiting on either a user input event
to arrive or (since yesterday ;-) an OS event to get signaled if any of the
other threads need to signal a semaphore within Squeak. I tried to (again
yesterday) increase the waiting timout in #idleProcess to the point when the
next delay will get active and it worked perfectly well. So unless something
happens, the VM won't do anything at all.

> This semaphore is signalled if real events arrive or 
> synthetic occur.  So this semaphore is actually a shared 
> queue.  A squeak Delay is mapped onto an OS timer event.

That's not even necessary - all you need is notice the VM to sleep at most
until the next delay wants activation.

> Blocking IO operations are spawned away as yet another
> thread which then blocks. 

That's more easily said then done. Threads are not an infinite resource and
managing a thread pool effectively is pretty hard.

Cheers,
  - Andreas