Re: [ANNOUNCEMENT] TEST: Cygwin 3.1.0-0.1

[Corinna Vinschen <corinna-cygwin@cygwin.com>]

[-- Attachment #1: Type: text/plain, Size: 2592 bytes --]

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?


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]