InputSemaphore on Windows

 
  Is there a reason why this isn't signalled when inputSemaphoreIndex > 0?

In sqWin32Window.c, the comment for synchronizedSignalSemaphoreWithIndex
looks somewhat scary...
But looking at the svn logs, it seems it never was used in the
record...Event() functions at all, so I wondered if a problem was
encountered before svn was in use that lead to its removal, or if it's
just not done by default?

Cheers,
Henry

 
On 4/15/2010 3:18 PM, Henrik Sperre Johansen wrote:
> Is there a reason why this isn't signalled when inputSemaphoreIndex > 0?

None. It just doesn't bite me. If it did I would've fixed it already.
Got patch?

> In sqWin32Window.c, the comment for synchronizedSignalSemaphoreWithIndex
> looks somewhat scary...
> But looking at the svn logs, it seems it never was used in the
> record...Event() functions at all, so I wondered if a problem was
> encountered before svn was in use that lead to its removal, or if it's
> just not done by default?

The short answer is that there are so many potential issues with
handling semaphore signals properly that at some point I just gave up.
At this point, there is no reliable way to deliver semaphore signals,
they can and they *do* get dropped (we've proven that).

Cheers,
   - Andreas

 
  On 16.04.2010 01:07, Andreas Raab wrote:
>
> On 4/15/2010 3:18 PM, Henrik Sperre Johansen wrote:
>> Is there a reason why this isn't signalled when inputSemaphoreIndex > 0?
>
> None. It just doesn't bite me. If it did I would've fixed it already.
> Got patch?
Not yet, thought I'd ask the question if there was any good reason not
to do so first :)
The reason I'd like it to be so, is that Pharo already includes a an
EventSensor (InputEventFetcher) which relies on this, and abolishes the
polling of EventSensor, but it's not used by default since
InputSemaphore is not signaled on all VM's. The code should be easily*
portable to Squeak as well. As far as I could read from the latest thread about it on the  Squeak
list http://n4.nabble.com/More-Delay-Semaphore-fun-td67556.html#a67556,
this is an issue mostly when the the waiting/signaling process is
terminated, which would (probably... ) not be the case for an event fetcher.

If I get the time to make any progress** I'll send you the modified file
for review.

Cheers,
Henry

*As in, I haven't done it, but the code should run on both platforms.
** Something buildable, which works as expected when InputEventSensor is
active on Pharo

On 16 April 2010 01:18, Henrik Sperre Johansen
<[hidden email]> wrote: This function is not called, because recordXXXEvent() is already synchronous
because VM calls handleEvents(), and during that, no interpreter
activity is possible,
so it is safe to modify an input semaphore state directly.
The synchronizedSignalSemaphoreWithIndex() is used only for cases,
when you need to signal a
semaphore from other thread, than interpreter runs in.

> Cheers,
> Henry
>



--
Best regards,
Igor Stasenko AKA sig.

On 16 April 2010 02:07, Andreas Raab <[hidden email]> wrote: Wait.. lets us separate the issues.
1) synchronizedSignalSemaphoreWithIndex() & friends, for signaling an
arbitrary semaphore
2) an input semaphore, which should be signaled if there are any
events pending for delivery into language side.

For (2) , i remember you promised to fix that in no time (a fix is
quite trivial) , so then newer images could finally
stop using polling and use an input semaphore instead.
Usually, it is not a big problem with dropping an input semaphore
signals ( if that's ever possible),
because events tend to come at a regular basis, so even if image-side
missed a signal, it can catch up later,
when next event will come by.

> Cheers,
>  - Andreas
>

--
Best regards,
Igor Stasenko AKA sig.