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 <[email protected]> > > > > Reviewed-by: > > > > Signed-off-by: Takashi Yano <[email protected]> > > > > ... > > > > 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
