From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 67595 invoked by alias); 15 Aug 2019 15:04:46 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 67586 invoked by uid 89); 15 Aug 2019 15:04:46 -0000 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 Received: from mout.kundenserver.de (HELO mout.kundenserver.de) (212.227.126.130) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 15 Aug 2019 15:04:43 +0000 Received: from calimero.vinschen.de ([24.134.7.25]) by mrelayeu.kundenserver.de (mreue012 [212.227.15.167]) with ESMTPSA (Nemesis) id 1MTfgb-1hqCqm0RnZ-00U139; Thu, 15 Aug 2019 17:04:37 +0200 Received: by calimero.vinschen.de (Postfix, from userid 500) id 71031A8073D; Thu, 15 Aug 2019 17:04:36 +0200 (CEST) Date: Thu, 15 Aug 2019 15:04:00 -0000 From: Corinna Vinschen To: Takashi Yano 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 , cygwin@cygwin.com References: <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) X-SW-Source: 2019-08/txt/msg00204.txt.bz2 --xvYBvMhxkRoMdQuV Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-length: 2550 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" Content-length: 833 -----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--