From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 85166 invoked by alias); 15 Aug 2019 15:09:19 -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 85151 invoked by uid 89); 15 Aug 2019 15:09:19 -0000 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 Received: from mout.kundenserver.de (HELO mout.kundenserver.de) (217.72.192.75) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 15 Aug 2019 15:09:16 +0000 Received: from calimero.vinschen.de ([24.134.7.25]) by mrelayeu.kundenserver.de (mreue108 [212.227.15.183]) with ESMTPSA (Nemesis) id 1MdeX1-1iXL0h19pB-00ZcVl; Thu, 15 Aug 2019 17:09:10 +0200 Received: by calimero.vinschen.de (Postfix, from userid 500) id 5DAB8A8073D; Thu, 15 Aug 2019 17:09:08 +0200 (CEST) Date: Thu, 15 Aug 2019 15:09:00 -0000 From: Corinna Vinschen To: Takashi Yano Cc: cygwin@cygwin.com Subject: Re: [ANNOUNCEMENT] TEST: Cygwin 3.1.0-0.1 Message-ID: <20190815150908.GQ11632@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> <20190815150436.GP11632@calimero.vinschen.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="DwegkxrocNF/g53g" Content-Disposition: inline In-Reply-To: <20190815150436.GP11632@calimero.vinschen.de> User-Agent: Mutt/1.11.3 (2019-02-01) X-SW-Source: 2019-08/txt/msg00205.txt.bz2 --DwegkxrocNF/g53g Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-length: 2875 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" Content-length: 833 -----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--