EventSensor /inputSemaphore

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

EventSensor /inputSemaphore

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

Reply | Threaded
Open this post in threaded view
|

Re: EventSensor /inputSemaphore

johnmci
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 <[hidden email]>
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
=
=
=
========================================================================



Reply | Threaded
Open this post in threaded view
|

Re: EventSensor /inputSemaphore

Igor Stasenko
On 26/12/2007, John M McIntosh <[hidden email]> 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.


--
Best regards,
Igor Stasenko AKA sig.