EventSensor /inputSemaphore

Igor Stasenko siguctua at gmail.com
Wed Dec 26 13:29:58 UTC 2007


On 26/12/2007, John M McIntosh <johnmci at 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.


-- 
Best regards,
Igor Stasenko AKA sig.



More information about the Squeak-dev mailing list