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.
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@smalltalkconsulting.com Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================
On 26/12/2007, John M McIntosh johnmci@smalltalkconsulting.com wrote:
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.
Thanks for clarification.
squeak-dev@lists.squeakfoundation.org
-
Igor Stasenko -
John M McIntosh