Re: [ANNOUNCEMENT] TEST: Cygwin 3.1.0-0.1

[Corinna Vinschen <corinna-cygwin at cygwin dot com>]

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 because
> > > 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.
> > 
> > Strangely, this problem also disappears with this patch.
> > 
> > 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 = NULL;
> > +         //tls->signalfd_select_wait = NULL;
> >           event = true;
> >           break;
> >         default:
> 
> 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.

Worse, thread_signalfd() closes the handle on exit, so keeping
signalfd_select_wait set may result in strange behaviour after select
returns.

> Any ideas greatly appreciated.


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer

Attachment: signature.asc
Description: PGP signature