DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:date:from:to:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; q=dns; s=
	default; b=rPKzRStkBLbd/2DCdbC9kuL0FnNE4WZngVDN4YqUrACQhOw6MJJh0
	52icOgfiLO3nMMpf1kpee19ltc3M/aHws0cbjLx9IBmquyjqfMZkoPNAiAbnSlo6
	0XJX1ShUaNug24Nq4OiqDzOeEE6WEsi0VwKads2KBahKu5araME5Pg=
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Date: Tue, 7 Mar 2017 15:33:06 +0100
From: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: Changing behaviour of pthread_cond_wait().
Message-ID: <20170307143306.GA4272@calimero.vinschen.de>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <20170307204318 DOT 8dda1744403eafdb79e2cf06 AT nifty DOT ne DOT jp>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;	protocol="application/pgp-signature"; boundary="zhXaljGHf11kAtnf"
Content-Disposition: inline
In-Reply-To: <20170307204318.8dda1744403eafdb79e2cf06@nifty.ne.jp>
User-Agent: Mutt/1.7.1 (2016-10-04)

--zhXaljGHf11kAtnf
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi,

On Mar  7 20:43, Takashi Yano wrote:
> Hello,
>=20
> I would like to propose chaging behaviour of pthread_cond_wait().
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> The test case acts as follows in Debian GNU/Linux and FreeBSD.
> % gcc pt.c -lpthread; ./a.out
> Thread 1
> Alarm 2
> Thread 3
> %
>=20
> However, in cygwin, it acs as:
> % gcc pt.c; ./a.exe
> Thread 1
> (Deadlock: ^C is needed to terminate.)
> %
>=20
> 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

--=20
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

--zhXaljGHf11kAtnf
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJYvsSiAAoJEPU2Bp2uRE+gD/4P/1SfQ8c3cAGs1/24ecSAUtrQ
Hyrnj/V+YOmQInl/tSsnJ4W+nfNfBe/UtDs561D+VxKmBaMU+K+fgWBvoiRsES1F
NhVi3LhToMi5Lp6Dnv6nOEN+3ksUudjtgna6Rg+EKW+nwhKmkWsfQB0L0iV7qVaK
0r1HsI44TV1SjMInvn+vDkB+53K9/sPF4e+U3T3it+uLQ8GrpdK/l36ZeQWK3nzT
xi2OOYpgt0VnvzKk4tySMLkSG2OriwmdEfvfBdARqmivPB51LGDsKxUR3yY352YI
UTdSqGX3m6PKlC/PLpvoAQvN6qbEPy+FLR+4ozgqJFWBOTTPkNkycGgrh1wPRwVL
EiY+/Mq5DurHp1627teBql998GRV0nhOyhGBAB4ukVcIyoN6NJEVXn8aST8tUlRP
fMVpNa826qgG1046VTbhwM0CMj8YvxlTQYVCoQW/aaE3WBW439VVLIzQ19CDiZtp
RDWf1EqTWXw3KW56UfoCBlgclkazb144TR9Lu6eJDpgFdnN2iDmHS5LU0I7d2rxA
GqEScr/e0CWNfKooX3tA5oHNORwm/CqH6ltY4TyUd68b3r2daaOs7vZDL8ISLyc6
t14Pr/jzEYGMZUWXoiarRB/e9Q2LT7qYbQ3NRDTb7xun1BRt/DAnuZdQ3pMEH51w
Bf03UxkHwQI8H+4WV2N2
=/xj4
-----END PGP SIGNATURE-----

--zhXaljGHf11kAtnf--