> Well I know that if I grab and click hold the separator bar in the  
> Browser window just above the senders button, then count to five,
> I count 80,000 signals to the semaphore, which is spining that
> ioProcess loop really really fast...
> As you mention both processes do this together so nothing really gets
> stacked up. However this is needless work...

Be that as it may but unless you fix the clients not to use Sensor there is
really nothing you can do. Sensor polls and because of the VMs event support
we have to make sure we get the appropriate state pulled in from the VMs
event buffer. If we don't, then the polling loop will sit there forever.

Besides, signalling the event semaphore from the VM will only work if you
have a multi-threaded VM implementation which can process incoming UI events
in parallel to the VM's loop. If you don't, then you'll only get new events
every 500ms or so (depending on what your VM interrupt check counter says)
so not stimulating the input semaphore is not an option given all the
non-multithreaded implementations.

I might add that I've been over all of this many, MANY times. While the
current version might be inefficient it is the only way to preserve the
expected notions from its clients - if you want to reduce the needless work
done here then you need to fix the clients to work with our (not so) new
assumptions (e.g., being event-driven no client should poll for state and
expect it to change in its polling loops). Once you do this, you can rewrite
everything in terms of the morphic hand rather than Sensor's polling API
(which is the right thing to do).

Cheers,
  - Andreas