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=
Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm
Sender: cygwin-owner@cygwin.com
Mail-Followup-To: cygwin@cygwin.com
Date: Thu, 15 Aug 2019 17:04:36 +0200
From: Corinna Vinschen <corinna-cygwin@cygwin.com>
To: Takashi Yano <takashi.yano@nifty.ne.jp>
Cc: cygwin@cygwin.com
Subject: Re: [ANNOUNCEMENT] TEST: Cygwin 3.1.0-0.1
Message-ID: <20190815150436.GP11632@calimero.vinschen.de>
Reply-To: cygwin@cygwin.com
Mail-Followup-To: Takashi Yano <takashi.yano@nifty.ne.jp>,	cygwin@cygwin.com
References: <announce.20190809185338.GZ11632@calimero.vinschen.de> <20190812224403.37e4ccfdcfb7046ed70fef16@nifty.ne.jp> <20190812153613.GN11632@calimero.vinschen.de> <20190813104753.GU11632@calimero.vinschen.de> <20190814204100.659fe40d928eae15338198a7@nifty.ne.jp> <20190814204717.caf6884b1216bbeee2f586d6@nifty.ne.jp> <20190814134900.GY11632@calimero.vinschen.de> <20190815042126.7c2f0baf57b4a82f7d013f74@nifty.ne.jp> <20190815074930.GF11632@calimero.vinschen.de> <20190815103638.GO11632@calimero.vinschen.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--