[PATCH] Cygwin: signa: Redesign signal queue handling

[Takashi Yano]

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?

-- 
Takashi Yano <takashi.yano@nifty.ne.jp>