EventSensor /inputSemaphore

John M McIntosh johnmci at smalltalkconsulting.com
Wed Dec 26 13:17:09 UTC 2007


inputSemaphore was introduced when the event logic moved from pure  
polling to events flowing up from the VM
on the event queue.

For the macintosh VM it was used to decide if the VM was supporting  
InputSensor or EventSensor, and later when OS-X came out for years the  
carbon VM actually used 2 processes. One pthread ran the interp.c  
loop, the other pthread ran the UI event process. Thus the  
inputSemaphore was signalled to tell the interpreter that yes the  
event process had stuck information onto the squeak event queue, along  
with using an operating system mutex semaphore to prevent race  
conditions between the two operating system processes when dealing  
with the queue.

However with this model Apple insists any UI activity must occur on  
the main thread, not child processes.

A few years back when Sophie was started and we were trying to  
integrate quicktime FFI calls it became apparent that we had to  
refactor the VM back to a single thread because of deadlocks between  
the interpreter FFI UI calls, and the VM main thread UI event handling.

Currently the macintosh carbon vm still signals the semaphore after  
placing events on the event queue.

On Dec 26, 2007, at 1:54 AM, Igor Stasenko wrote:

> I'm curious,
> in new EventSensor , which is replacement of InputSensor , there are
> ivar, called
> inputSemaphore , which should indicate that there are events waiting
> to be handled.
> But there is no code except initialization/shutdown, where it's  
> really used.
>
> Also, windows platform sources storing inputsensor index only to check
> that image is using new (EventSensor) framework for working with input
> events, but there is no code which signals it.
>
> Is that was introduced only to indicate how VM should behave (using
> old or new event handling mechanisms)?
> But then, why it's a semaphore, a simple flag is enough for that.
>
> -- 
> Best regards,
> Igor Stasenko AKA sig.
>

--
= 
= 
= 
========================================================================
John M. McIntosh <johnmci at smalltalkconsulting.com>
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
= 
= 
= 
========================================================================





More information about the Squeak-dev mailing list