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.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?
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.y...@nifty.ne.jp>
