2009/2/12 Andreas Raab <andreas.raab at gmx.de>:
> Igor Stasenko wrote:
>>
>> The inputSemaphore is not signaled by VM (win32), but instead used to
>> check how image polls its events.
>
> Oh. You are right. How pathetic is that! I should fix that ASAP.
>

Btw, Andreas. Currently, most images polling events by themselves and
never wait on input semaphore.

With new rewrite, there are 2 InputSensor classes with different
#waitForInput method behavior:

1. waitForInput
	inputSemaphore wait.

2. waitForInput
	self class eventPollDelay wait.

Now, if you will fix signaling the input semaphore, we need some way
to determine what method of event polling is most appropriate -  to
install a best event polling mechanism.
Any ideas how this can be determined by image side?
Maybe you can patch the
primSetInputSemaphore: semaIndex
	"Set the input semaphore the VM should use for asynchronously
signaling the availability of events. Primitive. Optional."
	<primitive: 93>

to return a true, if VM guarantees that it will signal the input
semaphore when new event occurs.
And any other value returned should mean, that image should keep using
old manual event polling mechanism and do not rely on input semaphore.


>> Btw, there is a refactoring of this stuff in Pharo, not sure if it
>> already incorporated in image. It was wtitten with idea kept in mind,
>> that there can be multiple event listeners at once, not just hand
>> morph.
>
> I'm not sure if having multiple listeners is useful at this level - all
> EventSensor does is pulling the events from the VM, packaging them up and
> passing them into the event queue for any downstream consumers. If there
> were multiple listeners in a morphic environment, they should probably be
> registering with the hand (which has such a listener mechanism already), not
> with Sensor. What's the use case for this refactoring?
>
> Cheers,
>  - Andreas
>
>
>



-- 
Best regards,
Igor Stasenko AKA sig.