Here, we do not intend to delve deep into the Linux kernel internal details of signal handling; rather, we'd like to make clear a common misconception hinted at earlier: handling signals is not at all like hardware interrupt handling. Signals are not interrupts, nor faults or exceptions; all of these— interrupts, traps, exceptions, faults—are raised by the PIC/MMU/CPU hardware on a computer. Signals are purely a software feature. 

Delivering a signal to a process implies setting some members in the task structure of the task (in kernel memory), the so-called TIF_SIGPENDING bit, and the particular bit(s) representing the signal(s) in the task's sigpending set; this way, the kernel knows whether, and which, signals are pending delivery to the process.

The reality is that at opportune points in time (which occur regularly), the kernel code checks whether a signal(s) is pending delivery, and, if so, delivers it, running or consuming the signal handler(s) of the process (in userland context). Signal handling is thus considered to be more of a polling mechanism rather than an interrupt one.