> if a signal is sent to a process while it is handling another signal then you can lose that signal
> signals not being queueable
Are you sure? I'm not an expert on signal handling, but I believe these statements are not true in the case of signalfd(2), which allows you to read signals from a file descriptor and does not require a signal handler.
Signal sending cannot block, so you'd need to have an unlimited amount of memory in order to guarantee that all signals are delivered. Not to mention that some signals allow you to block a process in the middle of a syscall (resulting in the lovely restart_syscall and EINTR hacks).
Also, signalfd(2) has its own lovely host of problems (caused by the fact that a file descriptor and signals don't match in abstractions). On fork(), sendmsg() or exec() or any other interesting event, the file descriptor starts to lean towards breaking POSIX. In addition, because of signals' interactions with threads, you get some even odder interactions when you read from the fd in a multithreaded program (they share the file descriptor table but will read different data).
Re:Linux Signals – Internals
by zAy0LfpBZLC8mAC on Saturday July 09, 2016 @07:29PM
(#12063822)
It is necessarily true because sending signals cannot block and queueing an unbounded number of signals would require unbounded amounts of memory.
Unix did a lot of things right, but signals was certainly not one of them. Sometimes the simple ideas aren't the best ones.