> > > As you mention both processes do this together so nothing
>  > > really gets stacked up. However this is needless work...
>
>  PS. Of course it is entirely irrelevant whether a polling loop like
>  [Sensor anyButtonPressed] whileFalse.
>  busy-loops within the io process or anywhere else. It's the nature of
>  polling loops to waste cycles so it really doesn't matter where you 
> waste
>  them ;-) Note that by your rough estimate it would mean we can run 
> approx.
>  10k io process loops per second (I would guess that the real number 
> is even
>  dramatically higher) so even trying to be a _little_ less agressively
>  polling by just waiting a single millisecond would mean we'd reduce 
> the load
>  on the system by more than 90% ;-)))
>
>  Cheers,
>  - Andreas

Ok, I've another version here. It has the pure interrupt driven 
subclass, but with a change to
delay for 2 milliseconds any polling activity at the point of doing the 
signal semaphore logic, which limits things to <500 calls a second. 
Thus doing a boarder stretch doesn't bury the CPU meter.

I considered 2 milliseconds versus 1 millisecond, so other processes 
could do work, besides at least on the macintosh the state of the mouse 
etc is updated every 16 milliseconds, so looking more often isn't  
useful. However I not sure about tablets or the like which might do 300 
measurements a second? So I wasn't quite happy with doing say a 5 ms 
wait.  Certainly I can't tell with a bit of testing any difference 
between 2 & 5ms.

Feedback is welcome.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: EventSensorDrivenByVM-JMM.5.cs.gz
Type: application/x-gzip
Size: 1305 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20030703/307af0f1/EventSensorDrivenByVM-JMM.5.cs.bin