Chris Angelico via Dng <dng@???> writes:
> On Tue, 7 Apr 2026 at 23:43, Didier Kryn <kryn@???> wrote:
>> You're right, the kernel implementation calls dequeue_signal() just
>> when the application reads from the file descriptor, which means
>> signalfd() is just a file-style API, but not a queue where the signals
>> would be stored. Too bad! It is nevertheless convenient to serialize the
>> signals, process them in the normal context of the application instead
>> of a signal handler, and wait for them at the same wait point as
>> possible other asynchronous events.
>>
>
> That's exactly how I usually use it - adding the signals to the set of
> file descriptors being monitored. So if I set that fd into an epoll
> group, when is dequeue_signal() called, and does it improve
> reliability?
The signalfd read function calls dequeue_signal.
Signal semantics remain the same: A signal is a software interrupt. It's
not a message sent to the process. Asynchronous signals (like SIGCHLD or
SIGINT) get raised when certain external events occur. And they remain
raised until the application has handled, that is, received the signal
in some way. Should the event reoccurs before the signal has been
handled, the process will still only receive one signal and not two.
::
Re: [DNG] Good thing we don't use s…
