[Pharo-project] Fwd: [Vm-dev] InputSemaphore on Windows
Begin forwarded message:
From: Igor Stasenko <siguctua@gmail.com> Date: April 18, 2010 3:00:02 AM GMT+02:00 To: Squeak Virtual Machine Development Discussion <vm-dev@lists.squeakfoundation.org> Subject: Re: [Vm-dev] InputSemaphore on Windows Reply-To: Squeak Virtual Machine Development Discussion <vm-dev@lists.squeakfoundation.org>
On 16 April 2010 02:07, Andreas Raab <andreas.raab@gmx.de> 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?
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).
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.
participants (1)
-
Stéphane Ducasse