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
|