X-Recipient:	archive-cygwin AT delorie DOT com
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:cc:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; q=dns; s=
	default; b=t/4prsaQfHmiZjBSSHcbpEJyWFurC1MT9KQAs6iAbClwO5OextLaU
	k56Qwkrh4yfNO8Jgd6uL2Rv+7gmGONA+Yn/Q3w45+kam9t6XpfwcxF4DEU03OEU4
	nYkiA4SHGt37dSVhi5dTdV10gs86aiuzbdL4Uz2qqcw1wyFbUqWvHM=
DKIM-Signature:	v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:date:from:to:cc:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; s=default;
	bh=TiGE7YbCeXSd0FU3kvRAD4Fp1WY=; b=HAvKN3NAAWAXO+UQRmDxSTQIRrLT
	8dSKkP/MnEvzNY/pSiDeyvYeLv163jMGao++rabPr9MU4lilYvW+3MnZxV+j0ZrV
	4KgkbRotutoA4fAtm6KIfSmNM8VOq669WuYkzK9p0sD0Uvr/1DNEpTgYn7qoD+o2
	S8EPIzIj4JEWw+k=
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com
Authentication-Results:	sourceware.org; auth=none
X-Spam-SWARE-Status:	No, score=-116.0 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_0,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,GOOD_FROM_CORINNA_CYGWIN,KAM_NUMSUBJECT,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 spammy=
X-HELO:	mout.kundenserver.de
Date:	Thu, 15 Aug 2019 12:36:38 +0200
From:	Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To:	Takashi Yano <takashi DOT yano AT nifty DOT ne DOT jp>
Cc:	cygwin AT cygwin DOT com
Subject:	Re: [ANNOUNCEMENT] TEST: Cygwin 3.1.0-0.1
Message-ID:	<20190815103638.GO11632@calimero.vinschen.de>
Reply-To:	cygwin AT cygwin DOT com
Mail-Followup-To:	Takashi Yano <takashi DOT yano AT nifty DOT ne DOT jp>, cygwin AT cygwin DOT com
References:	<announce DOT 20190809185338 DOT GZ11632 AT calimero DOT vinschen DOT de> <20190812224403 DOT 37e4ccfdcfb7046ed70fef16 AT nifty DOT ne DOT jp> <20190812153613 DOT GN11632 AT calimero DOT vinschen DOT de> <20190813104753 DOT GU11632 AT calimero DOT vinschen DOT de> <20190814204100 DOT 659fe40d928eae15338198a7 AT nifty DOT ne DOT jp> <20190814204717 DOT caf6884b1216bbeee2f586d6 AT nifty DOT ne DOT jp> <20190814134900 DOT GY11632 AT calimero DOT vinschen DOT de> <20190815042126 DOT 7c2f0baf57b4a82f7d013f74 AT nifty DOT ne DOT jp> <20190815074930 DOT GF11632 AT calimero DOT vinschen DOT de>
MIME-Version:	1.0
In-Reply-To:	<20190815074930.GF11632@calimero.vinschen.de>
User-Agent:	Mutt/1.11.3 (2019-02-01)

--qBjqo5c+GoerLc/a
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Aug 15 09:49, Corinna Vinschen wrote:
> On Aug 15 04:21, Takashi Yano wrote:
> > On Wed, 14 Aug 2019 15:49:00 +0200
> > Corinna Vinschen wrote:
> > > The only reason I can see is if sigwait_common() returns EINTR because
> > > it was interrupted by an unrelated signal.  This in turn lets the rea=
d()
> > > call fail with EINTR and that should be expected by the callers, in
> > > theory.
> >=20
> > Strangely, this problem also disappears with this patch.
> >=20
> > diff --git a/winsup/cygwin/select.cc b/winsup/cygwin/select.cc
> > index 9cf892801..82ac0674f 100644
> > --- a/winsup/cygwin/select.cc
> > +++ b/winsup/cygwin/select.cc
> > @@ -1869,7 +1869,7 @@ thread_signalfd (void *arg)
> >        switch (WaitForSingleObject (si->evt, INFINITE))
> >         {
> >         case WAIT_OBJECT_0:
> > -         tls->signalfd_select_wait =3D NULL;
> > +         //tls->signalfd_select_wait =3D NULL;
> >           event =3D true;
> >           break;
> >         default:
>=20
> The problem with not setting signalfd_select_wait to NULL here is that
> only a subsequent read or sigwaitinfo will do, so there's a time
> post-select which will reroute the signal wrongly.

Worse, thread_signalfd() closes the handle on exit, so keeping
signalfd_select_wait set may result in strange behaviour after select
returns.

> Any ideas greatly appreciated.


Corinna

--=20
Corinna Vinschen
Cygwin Maintainer

--qBjqo5c+GoerLc/a
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEoVYPmneWZnwT6kwF9TYGna5ET6AFAl1VNbYACgkQ9TYGna5E
T6CruQ//V+U54B8pUhCDtmOapRcLt3PjfW20WtODDyRvT9pOhjfbuHhKoBr1Nz65
DXWEarwopgabmNG5PTUHm3zCxib0BaqZGEJoy+ZA9K/zLMAwOZvxylJxzPuVQXAO
pRx6AQe9ORPDiwOHQEvOyFYNxQL/92T9jiFQAa/QgKVdp2L0XjiCoIZAn6/sRbPG
rNYXuaRHBsQ/OdH0Vk7OszSumMBDsXA4egigI9R+d+XdU5fiISt1/A/W/ExSuTv0
DOpk7rLbemRKwK48+/77oA1gUdGWRNML9oW6lx/zNvoLQkjzbs+VR9btCJsgIseB
pZLkUIwHMaLZwccYGv9hso2cgQ+br2U5HZyDrxTEJfTso7WghRiEt5nLRlErV1GG
5SlNNpTTU3JdEc2LuzuYeLhPvBPGciV3aGisFt18boIpke/27fFbDcRXqP5Igrv0
OxPmX5PkfoQm48JHPdLPrV6M/ycDgZl6WjNCVynHhfyvBE7JhBdUEm0ZsG3iX2Ik
xJ6hEqhdnd9/rm+gh4f7dWZr8SIbSm7JzYRbCBjHzlHMAKxAwyOAljYDuShQliZf
bzcHkDrIWtswsuNNL1fgk+v4Qk840gTncyryun3/z6X59TpjZM6NHrUg0FaAUoRu
EPnieYF8UU44F9UlZ5l0CVO8YrRHt2vDWuOn1d5/aYJ2NfzAfgM=
=A07C
-----END PGP SIGNATURE-----

--qBjqo5c+GoerLc/a--

- Raw text -