2009/4/20 Igor Stasenko <siguctua@gmail.com>:
> 2009/4/20 St�phane Ducasse <stephane.ducasse@inria.fr>:
>> Would a platform specific code or infrastructure help there?
>>
>
> There should be some kind of detection algorythm , which can switch
> between polling and waiting on input semaphore.
> My proposal is to change the primitive (primInterruptSemaphore:
> aSemaphore ) to return boolean value, showing that input semaphore
> signaling is available.
> Then the code can use polling or waiting depending on returned result
> (the primitive in older VM's don't return informal value - it just
> returns a receiver).
> Andreas disagree with this approach, saying that same could be
> achieved w/o changes in VM by checking if input semaphore ever
> signaled, and if so, then switch from polling (which should be
> installed by default) to waiting.
> Both ways is doable, and should work well, it just shows our different approach.
>

Andreas is right on this point, though your proposition makes thing simpler.
But if he didn't introduce support for event-driven loop in windows VM, he is wrong:
feeding a polling loop with an event-loop is easy, the reverse is not.
I bet he spent more time arguing in the thread, than necessary for introducing requested change in the VM :)
... unless...
I tried this in windows:
(SmalltalkImage current vmVersion. -> 'Squeak3.10.2 of ''5 June 2008'' [latest update: #7179]')

InputEventFetcher deinstall; install.
InputEventFetcher default. -> an InputEventFetcher

It seems to work like a charm, doesn't that mean that VM IS SIGNALLING the inputSemaphore?

Nicolas