Takashi Yano wrote:
The previous implementation of the signal queue behaves as:
1) Signals in the queue are processed in a disordered manner.
2) If the same signal is already in the queue, new signal is discarded.
Strictly speaking, these behaviours do not violate POSIX. However,
these could be a cause of unexpected behaviour in some software. In
Linux, some important signals such as SIGSTOP/SIGCONT do not seem to
behave like that.
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
...
A quick test with many runs of 'lostsig' testcase with or without
'taskset 0x1' no longer shows any problems. No SIGALRM were lost (not
required), [SIGTERM] is always printed after all [SIGALRM] (not
required), SIGCONT is never lost. The previous 'timersig' testcase also
still succeeds.
--
Thanks,
Christian
