Is there any case where anything remotely related to signals is not full of perils? UNIX has plenty of rough edges, but signals must be one of the worst..
A much cleaner and portable solution to the races triggered by duplicated and early signals is to set up a pipe and have signal handlers write the signal number to that pipe.<p>A write syscall is permitted in a signal handler and now you can (p)select/poll the signals like any other file descriptor
This isn't really a signals problem. This is a fundamentally racy API. Any decision of the form "go to sleep until this condition is true" can't be done reliably unless the code that decides "this condition" is atomic with respect to the entrance to the sleep state. That is, if the condition might change after you've decided it's false but before you suspend, you might never wake up.<p>There are lots of solutions to this. Synchronizing along a "queue" a-la file descriptors or semaphores is the most common. The generalization of this "suspend until" problem is captured by the "condition variable" abstraction, which combines the sleep with a lock that provides mutual exclusion and can be released atomically on suspend.<p>But the pause() system call didn't understand any of that, so it's unresolvably buggy without some extra layer somewhere to act as a backstop and wake up incorrectly-sleeping processes.
sigprocmask is a neat solution, but requires a syscall. Would it be theoretically possible to share the signal mask between the userspace and the kernel in no-cost way? I'm thinking vDSO style, mmaped var.<p>This could have big implications, for example most classic coroutine implementations using setjmp do some procmask dance.