Sorry for the delay.

From: Corinna Vinschen [corinna-cygwin@cygwin.com]
Sent: Friday, October 23, 2015 5:55 AM
> > I've attached a test case that I *think* gets into the right spot, at
> > least for 64-bit Cygwin 2.0.4.  That is, it hangs trying to receive
> > the signal, instead of terminating.  (This test passes (terminates) in
> > 32-bit Cygwin 1.7.9 and 64-bit Ubuntu 14.04.3 LTS.)
> 
> Thanks for the testcase.  I applied a patch which hopefully works as
> desired, at least to fix the immediate problem of the remaining pending
> signal when a thread exits.  I uploaded a new developer snapshot to
> https://cygwin.com/snapshots.  Please give it a try.

Thanks; that was fast!  I tried replacing cygwin1.dll with cygwin1-20151023.dll .

The original test case now works.  I checked some of my other tests,
and unfortunately some of them failed, so I extracted out a new test
case, which is attached.  My guess is that something is subtly different
about the timing on this test.

This new test hangs about half the time, and I have to use Windows Task Manager
to kill it (not Cygwin "kill"). Sometimes I see "pthread_kill: Unknown error -1" while
it hangs (meaning that pthread_kill returned -1 instead of an error number).

> > > >   - Multiple pending signals targeting different threads could
> > > >   coexist, even if they shared the same signal number.  This happens
> > > >   on Linux (Ubuntu 14.04.3), where I can generate two signals for two
> > > >   different threads, then sleep for a bit in each target thread, and
> > > >   finally have each thread receive its signal with sigwait()--neither
> > > >   signal is lost during the sleeping period.
> > >
> > > That requires to extend the handling for pending signals.  That's
> > > a rather bigger task...
> >
> > Yeah.  It's nice if threads don't interfere with each other, but this
> > part would indeed be harder to change.
> 
> I added that to my neverending TODO list.  Maybe I get around to it at
> one point.

I know the feeling.  No worries, and thanks.

-- John Carey