[PATCH] Cygwin: signa: Redesign signal queue handling

[Corinna Vinschen]

On Mar 11 17:56, Takashi Yano wrote:
> On Mon, 10 Mar 2025 21:57:52 +0100
> Corinna Vinschen wrote:
> > On Mar  9 13:28, Christian Franke wrote:
> > > Takashi Yano wrote:
> > > > ...
> > > > With this patch prevents all signals from that issues by redesigning
> > > > the signal queue, Only the exception is the case that the process is
> > > > in the PID_STOPPED state. In this case, SIGCONT/SIGKILL should be
> > > > processed prior to the other signals in the queue.
> > > > 
> > > > Addresses: https://cygwin.com/pipermail/cygwin/2025-March/257582.html
> > > > Fixes: 7ac6173643b1 ("(pending_signals): New class.")
> > > > Reported by: Christian Franke <Christian.Franke@t-online.de>
> > > > Reviewed-by:
> > > > Signed-off-by: Takashi Yano <takashi.yano@nifty.ne.jp>
> > > > ...
> > > >   void
> > > >   pending_signals::add (sigpacket& pack)
> > > >   {
> > > > ...
> > > > +  if (q->si.si_signo == pack.si.si_signo)
> > > > +    q->usecount++;
> > > > ...
> > > > 
> > > 
> > > This should possibly also compare the si.si_sigval fields. Otherwise values
> > > would be lost if the same real-time signal is issued multiple times with
> > > different value parameters.
> > 
> > Looks like this doesn't only affect RT signals.  I just read POSIX.1-2024
> > on sigaction,
> > https://pubs.opengroup.org/onlinepubs/9799919799/functions/sigaction.html
> > and this is what it has to say in terms of queuing:
> > 
> >   If SA_SIGINFO is not set in sa_flags, then the disposition of
> >   subsequent occurrences of sig when it is already pending is
> >   implementation-defined; the signal-catching function shall be invoked
> >   with a single argument. If SA_SIGINFO is set in sa_flags, then
> >   subsequent occurrences of sig generated by sigqueue() or as a result
> >   of any signal-generating function that supports the specification of
> >   an application-defined value (when sig is already pending) shall be
> >   queued in FIFO order until delivered or accepted;
> > 
> > This isn't quite what the Linux man pages describe.  Signal(7) says:
> > 
> >   Standard signals do not queue.  If multiple instances of a standard
> >   signal are generated while that signal is blocked, then only one
> >   instance of the signal is marked as pending (and the signal will be
> >   delivered just once when it is unblocked).  In the case where a
> >   standard signal is already pending, the siginfo_t structure (see
> >   sigaction(2)) associated with that signal is not overwritten on
> >   arrival of subsequent instances of the same signal.  Thus, the process
> >   will receive the information associated with the first instance of the
> >   signal.
> > 
> > Am I just confused or do these two description not match?
> 
> Yeah, I think Linux is not fully compliant with POSIX.
> My v2 patch intends signal queue behaves like Linux when SA_SIGINFO
> is not set. On the contrary, it behaves as POSIX states if SA_SIGINFO
> is set.
> 
> Does this make sense?

Absolutely.

The word "implementation-defined" in the POSIX docs give you allowance
to queue signales all the time, though.  Just something to keep in mind
if that simplifies things.


Corinna