2009/2/15 Andreas Raab <andreas.raab at gmx.de>:
> 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?
>

AFAIK, it wasn't published anywhere, try searching Pharo list
archives, it should be in attachments.

The refactoring was targeted to support multiple event handlers
instead of just single Sensor.
Currently i developing a new model, based on this but a little different.
- initially there will be a single event polling loop running,
governed by a EventListener class.
- an EventListener installs the polling loop and fetching events from VM
- once received, event buffer is converted to an instance of
corresponding KernelXXXEvent and then passed to event handler (kept as
inst var).

The EventListener is intentionally made as simple as possible, to
minimise the probability of changing it unless something changed in
VM. Its name speaks for itself, it listens for events from some
source, and in our case source is VM.

You are free to set a listener handle to anything you like, just make
sure it responds to #handleEvent: message.

Now, the most fun begins with implementation of handler.
First, i want to implement a handler, which will behave similarily to
what current Sensor does.
Next, when multiple host windows machinery will be ready, i will
replace it with dispatching handler, which will dispatch events based
on window id.
So, instead of chain:
VM -> listener -> Sensor -> hand
we will have something like:
VM -> listener -> window -> Sensor -> hand

of course, such replacement is not possible until we will get rid of
Display/World/Sensor globals in most critical places to make at least
most functionality work for multiple host windows.

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

I agree.. you convinced me to put everything into a single method :)
lets stop wasting our breath on this subtle detail :)


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



-- 
Best regards,
Igor Stasenko AKA sig.