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.fra...@t-online.de> > > Reviewed-by: > > Signed-off-by: Takashi Yano <takashi.y...@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? Corinna
