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=NOzVKDzIwD2rVvtZvbQCQQto2unEmzJ1BK0smutt1WRw5ipboJsrU
	4oFzrwnI+1kQUcuLLA/QakPWSxeA3CllvyNOL3yaO6K8qtKCqiS//ORkFsQskIwQ
	5vISBGtCVa/2po4haFHwt089pui0gUzSe5N0iQsXAUGOHY1N8+TUtQ=
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=MnyJ2KCSc97DCHyq6TzT7KxmbBc=; b=xyu+Sa5DvrVlPfXFJsVodULYwo10
	7VYgOt40f3ANYNmTqe5gMrTDpP61P9wfnKQqvDlJqrRSyWgD22q6QQwgKV1QOqNp
	fkAsRIWIupqGh+t3M1MwMNNhbC6aiOsIuYrEri9E/H7fN5eV2DexXg6b+loALhK/
	TY9rauxewchs9Xs=
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.3 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 17:09:08 +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:	<20190815150908.GQ11632@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:	<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> <20190815103638 DOT GO11632 AT calimero DOT vinschen DOT de> <20190815150436 DOT GP11632 AT calimero DOT vinschen DOT de>
MIME-Version:	1.0
In-Reply-To:	<20190815150436.GP11632@calimero.vinschen.de>
User-Agent:	Mutt/1.11.3 (2019-02-01)

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

On Aug 15 17:04, Corinna Vinschen wrote:
> On Aug 15 12:36, Corinna Vinschen wrote:
> > 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 be=
cause
> > > > > it was interrupted by an unrelated signal.  This in turn lets the=
 read()
> > > > > 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.
> >=20
> > Worse, thread_signalfd() closes the handle on exit, so keeping
> > signalfd_select_wait set may result in strange behaviour after select
> > returns.
> >=20
> > > Any ideas greatly appreciated.
>=20
> Here's a vague idea:
>=20
> Right now, signalfd_select_wait is not only used to signal select/poll,
> but also to keep the signal in the queue for the next call to read.
> This read call then calls sigwait_common under the hood.
>=20
> Afaics, the problem here is that the signal is still in the queue
> even after it has been, basically, assigned to the signalfd.  Because
> of that, any subsequent signal dispatch trigger will fire, in the above
> case select's own signal handling.
>=20
> My (really still vague) idea would be to remove the signalfd_select_wait
> code and call sigwait_common from select instead.  If it catched a
> signal, the signal will have been dequeued, as usual.  However, the
> select thread function thread_signalfd() would just call sigwait_common,
> too, then create a signalfd_siginfo record which gets assigned to the
> signalfd fhandler.  The read function would check if the record is
> valid and return that as first record in the read buffer, and only
> then it would fall back to sigwait_common calls itself.
>=20
> Does that sound feasible?

Reply to self: Not really because calling sigwait_common from the
thread_signalfd() function will run in the wrong thread with the wrong
tls.  Bummer again.


Corinna

--=20
Corinna Vinschen
Cygwin Maintainer

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

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

iQIzBAEBCAAdFiEEoVYPmneWZnwT6kwF9TYGna5ET6AFAl1VdZQACgkQ9TYGna5E
T6AaWA//bvv/qKRFOnwfzEYEaADFuJbyf4NtKsWRBKJInolmEzfYNdLeSUA0xwvI
qGG7SOb+62MQnFIAxwFNtWgzKIaijXqbxI303rPeWcQTQQSb/WeqHgwvhxaWZiGS
icapUVWWj0H8BnlH1O1cCohlpYZnLNS5JovaBJyU72m4BP8IZp2LNGhnXTr5sYzB
2hEKVtz3XwKk8CsT3DFE/eA0sof483LpVUqHhzlyC2H+M0/OowML1VBczVN/Qmx4
aFb3kyX6uFZHb+GoGk5EFlyQM/B12sXWshCm76co2liPeppEuq9MbzGQwdh0WT2Y
6QA+zd1ahZj+/aXNC2yPsozUE0jrMqTVEO0Ljf0Uvzwss7ui42X23kcPhMl4D002
+FhGEaDRuDZltDse+Vz9d4fvK9Qhvt82jl0Dyi3ixHvDljGbdEogUNeYGSr3lQfa
WcII0QVnTmxF6jCzNJBn9AN0kKN46AMGwzazIhNOYRa6rFpZ+y6kJmQ7ckcEMrJM
D8ktbzvTQ26mF0CPZ6aKqIoMTayvxSw1VxLeIEPwmW8zX0OvJeZEhHBq7NrnAn8D
ZZ/UWebdEzdIZkhnwvZPCKYUjbmuz58GHoV4RTXPmo2ErPR9YMpttu69dD82WCAF
q58ub5+W5k7q+HuLNcEq1REvRvD5StuMTzxwyXM0g3oUtb1hpYw=
=jGI0
-----END PGP SIGNATURE-----

--DwegkxrocNF/g53g--

- Raw text -