Hi Tim,

> > 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'.

But this value of wasteful is almost exactly zero, even today. If you're
running single-threaded and *don't* signal the event semaphore it is zero.
If you run multi-threaded and *do* signal the semaphore it is not zero, but
intentionally so as the idea is to get the events straight out of the VM
once it's there.

> 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.

Strictly speaking, yes. However, one of the things you should probably do
before claiming this to be inefficient, is to measure the average length of
your input queue. You might be surprised how few events are actually in
there.

> I suppose one possible fix would be to alter the VM
> to only set the number of signal to 1 rather than incrementing
> it.

No, if anything then the image-level code should reset it. The VM shouldn't
make any particular assumptions how the image-level code works. It could
equally well just suck one event out of the primitive.

> > 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.

It sure is but it may not be as simple as it sounds at first. You got to
keep in mind that we may have MVC clients, and those might get broken by
this severely.

> > 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.

Good!

Cheers,
  - Andreas