How to implement events on Unix?

Stefan Matthias Aust sma at 3plus4.de
Sat Feb 10 11:33:48 UTC 2001


At 09:49 09.02.01 +0100, Marcel Weiher wrote:
> > From: Stefan Matthias Aust <sma at 3plus4.de>
>
> > >Since almost all VMs currently use a single thread for running both,
> > >interpret() and the event processing loop, we have to be OUT OF
> > >INTERPRET() in order to receive an event.
> >
> > So we should use two threads.  I thought, the event semaphore was
> > introduced for exactly that reason.
>
>The funny thing is that using two threads doesn't really help
>because (a) the image will still poll for events (though more
>cheaply) and (b) the funky delays still happen (in the image) with
>even some droppage.

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 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.  Blocking IO operations are spawned 
away as yet another thread which then blocks.  The squeak process which 
issued the operation will wait on a semphore which will be signalled by the 
IO OS thread if it finishes.  An OS thread queries the OS event loop and is 
also responsible to synthesize events like timer events if the OS cannot do 
that.  That thread would signal and wake up the interpreter thread.

This way, I think, the system can both the as responsive as possible as 
well as save the optimum of CPU-cycles as it always tries to give control 
back to the operation system.

(To continue by rant in the previous email, I don't think, that the Mac is 
the best operation system to special tailor a squeak VM on just to make the 
other VMs try to emulate the mac behavior.  If you'd have started with 
let's say unix, we perhaps had now already a better VM architecture)

Variant 2. Make the interpreter truely thread safe and run multiple squeak 
interpreter threads.  Dedicate one thread as event gathering thread and 
make sure that this thread always do the screen updates.  Other threads way 
implement stepping or perform background tasks. The system however will 
stay responsive.  Actually, make up an architecture similar to how 
Java/Swing works opposed to variant 1 which - I think - describes a way 
similar to VisualWorks.

bye
--
Stefan Matthias Aust \\ Truth Until Paradox





More information about the Squeak-dev mailing list