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
|