Changing behaviour of pthread_cond_wait().
Tue Mar 7 14:33:00 GMT 2017
On Mar 7 20:43, Takashi Yano wrote:
> 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.
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 819 bytes
Desc: not available
More information about the Cygwin