I found a second problem which may or may not be related:

If two threads use pthread_kill() to send each other the same signal,
such that the signal should be separately pending on both threads at
the same time, only one of the two signals is actually queued. It
seems that pthread_kill() is ignored if the same signal is already
pending on some other thread.

I've attached another demo program where two threads send each other
the same signal at the same time. On Linux and Mac, both are
delivered. On Cygwin, one or the other signal is delivered randomly,
but never both.

Same version: CYGWIN_NT-6.1 3.0.7(0.338/5/3) 2019-04-30 18:08

-Kenton

On Sat, Jul 6, 2019 at 3:46 PM Kenton Varda <kenton@cloudflare.com> wrote:
>
> Hello Cygwin,
>
> According to the (Linux) man page: "sigpending() returns the set of
> signals that are pending for delivery to the calling thread"
>
> However, on Cygwin, sigpending() seems to return the set of signals
> pending on any thread, as shown in the attached test program.
>
> Among other things, this can cause deadlocks in programs which use
> sigpending() to check for pending signals, then use sigsuspend() to
> induce delivery of the specific signals that are pending. Because the
> signal is not actually pending on the current thread, sigsuspend()
> will unexpectedly block, potentially forever.
>
> Output of test program:
> $ uname -srv
> CYGWIN_NT-6.1 3.0.7(0.338/5/3) 2019-04-30 18:08
> $ gcc -std=c11 -Wall test-sigpending.c -o test-sigpending -pthread &&
> ./test-sigpending
> sending signal to child thread with pthread_kill()...
> sigpending() says signal is pending in main thread (WRONG)
> sigpending() says signal is pending in child thread (CORRECT)
> received signal in child thread (CORRECT)
>
> The program works correctly on Linux.
>
> -Kenton