Le 06/04/2026 à 15:55, Rainer Weikusat via Dng a écrit :
> Didier Kryn <kryn@???> writes:
>> Le 06/04/2026 à 12:57, Rainer Weikusat via Dng a écrit :
>>> Traditionally, the set of pending signal is bitmask, this means only one
>>> signal of every kind can be pending at the same time. Judging from code
>>> I read yesterday, Linux queues one non-realtime signal but this still
>>> only makes two. Since the issue is timing dependent, some fiddling may
>>> be necessaary to demonstrate the effect, but this program:
>>     It is well known that signals can be missed, because of this. You
>> can use signalfd() to serialize them, thouth I'm not sure it
>> completely grants to not miss any.
> The signal manpage (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.

    With signalfd(), the kernel queues the signals into a pseudofile
descriptor, The application normally blocks the signals it asks to
receive by this means. It isn't specified in the man page if there can
be a race condition in the kernel, which would allow to loose these
signals. In the absence of mention, I think we can assume that signals
processed by this means are safely queued.

--     Didier