Lex,

> In this situation, it seems like a good idea for the Smalltalk-level
> code to do initSignals whenever it wakes up from a semaphore. 

See my response on this - it's impossible that this is the problem.

> If you are thinking of refactoring it, I might suggest 
> another setup of all this code.  Simply have EventSensor>>nextEvent
> ask the VM for an event, and if the primitive fails you synthesize
> an event.

That sounds suspiciously like what I proposed a while ago in a discussion
about potential slowdowns on PDAs ;-) Sadly, noone ever tried it (or lived
to report about it? ;) But you are right, it should work.

> Additionally, the VM's need to be sure that whenever a legacy polling
> primitive is called, they clear their event queue.  (They need to do
> something like this, anyway, in order to deal with legacy images.) 

They don't even have to clear it - silently overflowing the VMs internal
event buffer works just fine ;-)

> As one caveat, EventSensor needs to be careful to simulate the legacy
> polling methods by remember the newest event; if it uses the real
> primitive, the VM might clear the event queue and lose events.

That's exactly what EventSensor does these days - if you look at it you will
find that the "primitive state" is in its inst vars which work nicely. All
the code is there and it's all working - the only thing one needs to do is
to rip out the io process loop (which was introduced for reasons which
simply no longer apply).

Cheers,
  - Andreas