[BUG][FIX] interrupt driven EventSensor ( could somebody provide detailed review, please? )

Tim Rowledge tim at sumeru.stanford.edu
Thu Jul 31 20:35:39 UTC 2003


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

> Couple of notes:
> > 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.
> 
> The intended use of the input semaphore is for multi-threaded VMs *only*.
> Signalling the input semaphore unless you're running multi-threaded is
> currently pretty pointless. If the Unix-VM does it anyway, then it's a
> problem of the Unix VM not of EventSensor.
I think you missed the thrust of my comment here; it's not that the vm
shouldn't be signalling inputSemaphore but that signalling it for each
event is 'wasteful' for some value of 'wasteful'. Since all available
events are sucked out of the VM for a single decrement of the
semaphore's signals it is pointless to go round again and again merely
to use up those signals. I suppose one possible fix would be to alter
the VM to only set the number of signal to 1 rather than incrementing
it.

> 
> > 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
> 
> Actually, no. Even on Windows we have to do a bit of "keep-alive queries"
> (for various reasons) and using the combination of #primNextEvent and
> #primReliquishProcessorBlaBla works perfectly fine and is a pretty accurate
> model as far as I can tell. If Squeak is in some "deep computation" it
> wouldn't do any queries on InputSensor either so the model is not that
> different as one might think.
In a 'deep computation' we only get the checkForInterrupts half-second
tick and the ioProcess half-second tick, which may be enough to keep a
Windows VM happy but isn't really good for RiscOS nor I suspect Mac OS
<9. In a headless system we'd not get primNextEvent et al. at all from
the UI side of course. As long as the idleloop primRelinquish can
provide suitable occasional OS polling I think that would be ok.
 
> > 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.
> 
> Nobody has ever provided any numbers in this area despite giving precise
> instructions on what to do, so I must assume that there is no significant
> difference.
I don't think it needs to make a noticable performance improvement -
simply making the system simpler is a worthy goal.

> One final aspect: EventSensor has been working perfectly well in the last
> couple of years in varying environments. I don't see much reason to change
> anything unless either someone shows that things can get significantly
> faster by certain changes or someone provides an alternative for review and
> discussion.
Indeed. I'm hoping to foster discussion and suggestions for cleaner code
right now.


tim
--
Tim Rowledge, tim at sumeru.stanford.edu, http://sumeru.stanford.edu/tim
A computer's attention span is only as long as its extension cord.



More information about the Squeak-dev mailing list