Re: [ANNOUNCEMENT] TEST: Cygwin 3.1.0-0.1

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

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 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.
> 
> 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?

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

-- 
Corinna Vinschen
Cygwin Maintainer

Attachment: signature.asc
Description: PGP signature