SIGINT lost while program calls PeekMessage

[Corinna Vinschen]

On Jul  6 14:16, Jon Beniston wrote:
> Hi Corinna,
> 
> >Since your example code is running very tightly most of its time inside
> >some Windows system DLL function, there's next to no chance to interrupt
> >the thread to inject the signal handler call.  Cygwin tries this 100
> >times per signal.  If that fails, the signal gets lost.
> >
> >One way to solve this problem is adding a Cygwin call into the loop,
> >like the aforementioned usleep.  When a Cygwin call is performed, the
> >signal handler will be called as soon as the Cygwin call returns to
> >user-space.
> >
> >The bottom line is, Cygwin user space signal handlers and lots of
> >Windows-only calls in a tight loop don't work nicely together.
> 
> Ok, thanks for the explanation. In the real application, there is some
> actual processing inside the loop, besides the call to PeekMessage and more
> signals get through (Probably 75%), I just cut the code down to make a
> simpler test case. I'll add a Cygwin call as suggested.

Actually, if the application is using lots of Windows calls and (almost)
no Cygwin calls, I'd suggest to drop signals in favor of utilizing the
Windows message queue to signal specific states to the executable.

As for Cygwin's signal handling, it's a bit finicky in border cases,
and the fact that a signal can be queued only once is not very 21st
century either.  I haven't got a grip on these problems yet, but I'll
look into them for sure at one point.


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer