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=ibngpSyzC69hbJRo1UlXSxUN/8MIvncBKyYiqF/lqrohTGYWXK6oV
	DZ2yB/N5aEc5ZfTcrgSJbS61qTAcuuvC+qBivbweOVzdS1QW+HD49PjONK18bwDK
	fB8Erw5istQ4IEcaGowrg0WyVpZdpsINqYaIYYsNpfqIRNaEmbmaqk=
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=a75YKgEqMyDyYbS6VtuQaMt+CFo=; b=dP7l2K1JCscT7GiDdP79FVsMhGr8
	+eIqCt7VKO4sj1M1GrTbGjGqIypGeJ0/ejFJF/MPXSAKGlPv2Il5u58aNCDUZcpB
	cMF4oqUQGQKKRcODock8+tXRPLsbxsP47PHpOZDuRfVuuAmli6aq51a22hGGUyBX
	HfsDjXpOPfV+PUM=
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.1 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=vague
X-HELO: mout.kundenserver.de
Date: Thu, 15 Aug 2019 17:04:36 +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: <20190815150436.GP11632@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> <20190815103638 DOT GO11632 AT calimero DOT vinschen DOT de>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;	protocol="application/pgp-signature"; boundary="xvYBvMhxkRoMdQuV"
Content-Disposition: inline
In-Reply-To: <20190815103638.GO11632@calimero.vinschen.de>
User-Agent: Mutt/1.11.3 (2019-02-01)

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

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 beca=
use
> > > > it was interrupted by an unrelated signal.  This in turn lets the r=
ead()
> > > > 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.

Here's a vague idea:

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.

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.

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.

Does that sound feasible?


Corinna

--=20
Corinna Vinschen
Cygwin Maintainer

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

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

iQIzBAEBCAAdFiEEoVYPmneWZnwT6kwF9TYGna5ET6AFAl1VdIQACgkQ9TYGna5E
T6Drnw/8CtYRjUevqVFwCMFMNisM8m6AFH5fg4iMR4B/AeFSnxpsxpiNyU3cYVA1
MJkjQKDbipvumFOAn47lJx1m/z6i9xUCn0T+bIdcyII3y9yL+EUn4nXA+XbPuC9y
1TIeg84dXK4xqQ3gmRm2GpxgAuPG2DN2J5FRpp8PghS93BrAjLHiQC2MMmrF6grc
kX6qSMUL3pi3DOstyXDYOHh7z9JoOGEKOuWPWk6I9wNQdcn8cyj/PeuTJi+nxgJj
UZwywckTL3p6NrUEGi8W7qRPULIfNkEtGF2f9s92jmaLjdktrncyqRv7kSzlkKCj
Bl+AzyWMzqsWmdAE8YTkhdlgKAzmIZ91DC3dKndpAfkcH59JIUNLysAUmX7HCrpg
SGrhCVDygIiTr8+tIgUjG0saR6qGScZfdl+7oKZUQGqHEpFdt7RWQbH83itGp+wT
RFTcOyLDQnWoSA+78Lt04F+AbLob67x751os35MnZ1OrWNfhGPPoqmXYX+YKPiYu
LZGd2Runv+45dUYnXjsl+AosZF9QXRlFIDLoWkSmDNnnlyczbphMKGd00gR09CXX
RSchs4alvv4t4wiPSq8mX1ad7gGHNqeQHqxJRsBE4yodPSCb88M9Gma6rPb+IY5O
SP849v3SbbKHFovUnztKcdUVHxhqm/C9AHA6iUv3iwYx1/M6Nlc=
=Na33
-----END PGP SIGNATURE-----

--xvYBvMhxkRoMdQuV--