The name derives from POSIX and it denotes interrupts that occur due to the code that a particular thread executes. They are largely equivalent to C++ and Java exceptions, and in Windows they are called "unchecked exceptions."
Common Lisp programs may generate mostly three kinds of synchronous signals:
Floating point exceptions, that result from overflows in computations, division by zero, and so on.
Access violations, such as dereferencing NULL pointers, writing into regions of memory that are protected, etc.
The first family of signals are generated by the floating point processing hardware in the computer, and they typically happen when code is compiled with low security settings, performing mathematical operations without checks.
The second family of signals may seem rare, but unfortunately they still happen quite often. One scenario is wrong code that handles memory directly via FFI. Another one is undetected stack overflows, which typically result in access to protected memory regions. Finally, a very common cause of these kind of exceptions is invoking a function that has been compiled with very low security settings with arguments that are not of the expected type -- for instance, passing a float when a structure is expected.
The third family is related to the multiprocessing capabilities in
Common Lisp systems and more precisely to the
mp:interrupt-process function which is used to kill,
interrupt and inspect arbitrary threads. In POSIX systems ECL informs a
given thread about the need to interrupt its execution by sending a
particular signal from the set which is available to the user.
Note that in neither of these cases we should let the signal pass unnoticed. Access violations and floating point exceptions may propagate through the program causing more harm than expected, and without process interrupts we will not be able to stop and cancel different threads. The only question that remains, though, is whether such signals can be handled by the thread in which they were generated and how.
In addition to the set of synchronous signals or "exceptions", we have a set of signals that denote "events", things that happen while the program is being executed, and "requests". Some typical examples are:
Request for program termination (SIGKILL, SIGTERM).
Indication that a child process has finished.
Request for program interruption (SIGINT), typically as a consecuence of pressing a key combination, Ctrl-C.
The important difference with synchronous signals is that we have no thread that causes the interrupt and thus there is no preferred way of handling them. Moreover, the operating system will typically dispatch these signals to an arbitrary thread, unless we set up mechanisms to prevent it. This can have nasty consequences if the incoming signal interrupt a system call, or leaves the interrupted thread in an inconsistent state.