"Brent Vukmer" <bvukmer at blackboard.com> wrote:

> Andreas( and all EventSensor gurus ) -
I'm not going to claim to be an EventSensor guru but I have been playing
one on tv recently.

My current opinion is that the InputSensor/EventSensor classes are such
a mess right now that it would be smarter to replace them than just add
a bandaid, no matter how good it might be.

Some examples of badnessicity I've discoverated:-

a) If the VM signals the inputSemaphore for each event added to the
queue then the ioProcess will loop 'signals' number of times. Sounds
sensible? Sure, except that each time through the loop it has an inner
loop that calls nextEvent (which calls the primitive) until an empty
event is returned. So if there are a dozen events in the VM queue we go
into the ioProcess loop, into the inner loop, call the prim 13 times,
then out to the main loop, back in etc etc for a total of 25(?) calls to
the prim, 13 of them doing nothing useful. Depending on how the prim is
implemented this might add up to significant work. For example in the
copy of the *nix code I have sitting in front of me (quite possibly out
of date, I know) any call to ioGetNextEvent will call ioProcessEvents
if the VM queue is empty. Since we know that we are hitting this 13
times out of 25, and then rely on aioPoll (in
platforms/unix/vm/sqaio.c). Supposedly this will be fast if there are no
pending X events but then you're relying on X to do its job properly
:-).
So far as I can work out, the unix VM is the only one that actually
signals the inputSemaphore for each event, although the Mac VM seems to
signal in some cases. The windows VM seems to use inputSemaphore simply
as a flag that events are preferred over polling apis. Acorn now does
events and uses inputSemaphore in prety much the same way.
At the lowest levels of the VM there are conflicting needs for events
handling. Acorn, for example and rather like MacOS9, needs frequent
event polling to let the system keep running. Any OS that does threading
for io can presumably avoid worrying about that. This means a big
difference in behaviour if the only time that event polling happens is
when the nextEvent prim is called (we can almost ignore the once every
half-second check currently built into the checkInterrupts part of the
interpret loop, it's so rare) or if a thread is polling more frequently
and independently.
Yeuch - I really don't feel like I've explained that terribly well.

b) the ioProcess loop is pretty pointless. All it does is transfer info
from a queue in the VM to a queue in the image. I strongly suspect (and
I think Andreas suggested it a while back) that making Sensor>nextEvent
directly call the prim would work perfectly well. It would even save
cycles by not resulting in as many process switches. The inputSemaphore
waitTimeoutMSecs: has some small value in providing an occasional tickle
of the OS polling, but the default interval is very rare.


c) Once upon a time EventSensor was only used in Morphic projects and
InputSensor was used in MVC projects. I can't find any evidence that
InputSensor is used at all any more. Kill it. Simplificationise it.

d) Consider the confusion between eventQueue and keyboardBuffer in the
InputSensor hierarchy. I see no way that we can have a nil eventQueue
anymore. Lots of potential cleanup here.

e) The class var EventPollFrequency seems pretty redundant too. Not to
mention poorly named, since it is a delay time not a frequency.

Ouch, my fingers hurt from typing too much. Enough for now.

tim
--
Tim Rowledge, tim at sumeru.stanford.edu, http://sumeru.stanford.edu/tim
Strange OpCodes: RG: Read inter-record Gap