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

Yeah. I just don't like the whole subsystem all that much and having 
more InputSensor subclasses looks to me as if it may be making things 
worse. BTW, where is that code?

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

Yes. Although it seems that you don't get to avoid whatever complexity 
is required to decided which version to use. This is partly why I'm 
thinking it may actually be simpler to have this in the same place, 
along the lines of:

processEvents
   self waitForInputPolling.
   haveSema := inputSemaphore isSignaled.
   [true] whileTrue:[
     haveSema
         ifTrue:[inputSemaphore wait]
         ifFalse:[self waitForInputPolling].
     self processNextEvent.
   ].

Really not much complexity here.

>>> 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).

What could be clearer than actually checking? ;-) Seriously, I find this 
the most straightforward way to figure out whether we can rely on the VM 
to signal the semaphore or not if you really want to be have that level 
of backwards compatibility. Alternatively, just require VMs that signal 
the damn semaphore! ;-)

Cheers,
   - Andreas