Berserk idleLoop in event handling?

Tim Rowledge tim at sumeru.stanford.edu
Fri Jan 9 01:28:43 UTC 2004


"Andreas Raab" <andreas.raab at gmx.de> wrote:

> > if the idle loop doesn't get to run much
> > then the event polling is pretty rare. This might become a problem in
> > some situations I suppose.
> 
> No. If you poll for events when asked for new ones (via ioGetNextEvent or
> the state based primitive set) the idle loop really is only ensuring we
> respond in a more timely manner.
Well yes but it can devolve to depending on the delay set to
EventPollFrequency (which is so poorly named it's funny - it's the
inverse) mSecs. Currently that is typically 500 mSecs so it can get as
bad as a half second latency just from that. If some other idleloop
were setup that failed to call the relinquishCPU prim (and we both know
that someday someone will do that) we would be irritated by such a
delay/latency.

> Trust me, this stuff works. It is more complex than it strictly needs to be
> (as I explained in various previous messages the event sensor's ioProcess
> isn't needed since the VMs all do internal buffering) but it certainly
> works.
I agree that it works reasonably well but it certainly needs some
cleanups (such as the aforementioned dropping of ioProcess) these days.

For a start we still have InputSensor and EventSensor rather than a
single class, yet we always install an EventSensor on startup. There are
a number of places where a non-nil eventQueue or keyboardBuffer instvar
is used as some sort of discriminant for whether to behave as an event
sensor or and oldstyle sensor - but it looks like an eventQueue is
always installed on startup. There seems to be two places where events
might be simulated from older prims. EventPollFrequency is set to 500
every event fetch.

The ioProcessLoop runs too many times if the VM signals the inputSemaphore
for each event, since it runs to empty the vm queue for each signal. On
platforms where calling the next event prim has to poll the OS for new
events that can cost a good deal of time. Either we should call
primGetNextEvent once per signal or we should flush the signals in the
ioProcessLoop. Or fudge the vm to only signal once for each batch of
events?

A volunteer to clean this up would be welcomed as a hero. By me, at
least. I'm in the last throes of packing for The Big Move and won't be
online for much longer until it is all done, so can't hope to do much
with it now.

Oh and I'm still not sure why I seem to get gazillions of calls to
primRelinquishCPU between a keypress and a display. Another time maybe.

tim
--
Tim Rowledge, tim at sumeru.stanford.edu, http://sumeru.stanford.edu/tim
Useful random insult:- Immune from any serious head injury.



More information about the Squeak-dev mailing list