2009/2/14 Andreas Raab <andreas.raab at gmx.de>:
> Igor Stasenko wrote:
>>
>> 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:
>
> Seriously? Even more InputSensor classes? (*rolling his eyes*)
>
yes, the base class using inputSensor, and subclass using polling. The
difference in only a few methods.

>> 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?
>
> Easy. Run the poller until the first event comes in. Check whether the
> semaphore is signaled. Switch to non-polling if so. Alternatively, use
> #waitTimeoutMSecs: - it means you're still occasionally polling but that is
> probably acceptable.
>
Sure it is easy. I'm just feel uncomfortable when we need to introduce
more complex logic in places where its not necessary.
That's why i made two subclasses by factoring out #waitForInput logic
to avoid putting too much if's into a single method.
Again, when in future we will no longer need to care about backward
compatibility, you'll need a minimal change - simply stop using the
subclass instead of analyzing the complex code to remove obsolete
cruft.

>> And any other value returned should mean, that image should keep using
>> old manual event polling mechanism and do not rely on input semaphore.
>
> How much backwards compatibility do you need? Wouldn't it be easier to fix
> it and then switch?
>
I want it to be backward compatible, but i prefer a clear ways to
determine VM's behavior instead of impirically guessing it (as with
checking if semaphore is signaled).

> Cheers,
>  - Andreas


-- 
Best regards,
Igor Stasenko AKA sig.