Hi, On Mar 7 20:43, Takashi Yano wrote: > Hello, > > I would like to propose chaging behaviour of pthread_cond_wait(). > > POSIX states as follows about pthread_cond_wait(): > If a signal is delivered to a thread waiting for a condition variable, > upon return from the signal handler the thread resumes waiting for the > condition variable as if it was not interrupted, or it returns zero > due to spurious wakeup. > > cygwin 2.7.0 employs the latter behaviour, while Debian GNU/Linux and > FreeBSD employ the former one. Of course, this is not a cygwin bug. > However, IMHO, it is better to have the compatibility with the other > major platforms. > > Because of this difference, iperf 2.0.5 is not terminated normally in > cygwin 2.7.0. In client mode, iperf 2.0.5 does not stop after measurement > automatically. It needs ^C to stop it. In server mode, iperf 2.0.5 can > not stop even by ^C. Simple test case, attached (pt.c), reproduces this > problem. I know this test case (and iperf 2.0.5) is essentially unsafe > because pthread functions are called from signal handler. But, anyway it > works in Debian GNU/Linux and FreeBSD. > > The test case acts as follows in Debian GNU/Linux and FreeBSD. > % gcc pt.c -lpthread; ./a.out > Thread 1 > Alarm 2 > Thread 3 > % > > However, in cygwin, it acs as: > % gcc pt.c; ./a.exe > Thread 1 > (Deadlock: ^C is needed to terminate.) > % > > I would like to propose a patch attached (pthread.patch), for the above > reason. With this patch, iperf 2.0.5 as well as the test case works fine.
I applied a patch to change the behaviour as proposed, and uploaded new snapshots to https://cygwin.com/snapshots/ for testing. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat
signature.asc
Description: PGP signature
