Should you be scared of Unix signals? (2016)
So signals make sense once you understand where they came from.<p>The writers of Unix needed a kernel-&gt;user downcall mechanism.  Back then, user mode code was thought of as being like what we know call unikernels with the kernel thought of a bit more like a hypervisor.  The individual user sessions were, early on in Unix&#x27;s history, only a couple more primitives on top of what we&#x27;d later think of as DOS style environments, simply multiplexed on the hardware.  From that perspective, mirroring the microcode-&gt;kernel downcall mechanism (interrupts) at the kernel-&gt;user boundary makes plenty of sense.<p>Once you see them for what they are (interrupts for user mode instead of kernel mode), all of their goofiness makes sense.<p>* SIGSEGV, SIGILL, etc. map to processor exceptions.<p>* SIGIO, SIGWINCH, etc. map to I&#x2F;O device interrupts, including SIGALRM as a timer interrupt.<p>* SIGSTOP, SIGKILL, etc. map to platform interrupts like NMIs.<p>* SIGUSR, etc. map to IPIs.<p>It&#x27;s a one shot downcall mechanism that can happen at any time, so all of the same way you think about concurrency during an interrupt applies here as well.  You can&#x27;t take a regular mutex because it might already be held by the context you interrupted.  Less of a deal now, but any non-reentrant code shared with the regular user context is off the table.  So just like how in interrupt context, large swaths of the kernel are off limits, large swaths of user mode are off limits except very carefully written, very context dependent code.<p>I even ported an RTOS to run in *nix user mode for CI&#x2F;development purposes, where the interrupt controller abstraction was simply implemented as signals.  The code didn&#x27;t look any different than you&#x27;d expect from running under a hypervisor with a paravirtualized interrupt controller.