lost signal (was: cygwin 3.6.0: Signals may fail permanently if received after SIGSTOP)

[Roland Mainz]

On Fri, Mar 7, 2025 at 8:29 AM Takashi Yano via Cygwin
<cygwin@cygwin.com> wrote:
> On Wed, 5 Mar 2025 11:23:26 +0100
> Christian Franke wrote:
[snip]
> > A 'ps' is a second terminal then shows that the child process is still
> > in S)topped state. 'kill -CONT ...' works to continue.
> >
> > If the testcase is assigned to a single core with 'taskset 0x1 ...', it
> > apparently always hangs.
>
> Thanks for the report and the testcase.
> The current implementation of the signal queue has the following problems:
> 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.

Erm... that is actually the intended POSIX behaviour *except* for
SIGRT* signals. Any signal coming queued more than one time *CAN* (it
is not a requirement, and for some signals it's not useful, like
|SIGCHLD|, because their siginfo data cannot be folded) be "folded"
into one signal.
The only exception in the POSIX standard are realtime signals, which
have a realtime signal queue, and |sigqueue()| has a return code which
indicates when the preallocated storage for realtime signals and their
payload (see |sigval| argument in
https://pubs.opengroup.org/onlinepubs/9799919799/functions/sigqueue.html)
is full.

----

Bye,
Roland
-- 
  __ .  . __
 (o.\ \/ /.o) roland.mainz@nrubsig.org
  \__\/\/__/  MPEG specialist, C&&JAVA&&Sun&&Unix programmer
  /O /==\ O\  TEL +49 641 3992797
 (;O/ \/ \O;)