4 ms·
> * SIGSEGV, SIGILL, etc. map to processor exceptions. That's the idea anyway. But you can also `kill -SEGV $SOMEPID`. There are (now, since threading became a
by scottlamb 3y ago
> * SIGSEGV, SIGILL, etc. map to processor exceptions.
That's the idea anyway. But you can also `kill -SEGV $SOMEPID`. There are (now, since threading became a thing on Unix) three categories of signals:
* async, process-directed, as with the command above, SIGALRM, or the like.
* async, thread-directed, as with `pthread_kill`.
* sync, thread-directed, as with the processor exceptions you mentioned.
The signal numbers generally are good enough, but the `si_code` member of `siginfo_t` will more authoritatively distinguish the source of a signal.
Anyway, I agree it's useful to think about the type of signal you're interested in handling. I think most people are primarily interested in async, process-directed signals for graceful shutdown on `SIGTERM`/`SIGINT` and/or config reloading on `SIGHUP`. Fortunately, that's the easiest to handle safely. One of my favorite ways is to not use a signal handler at all. Mask out the signal in main() before creating any threads, and create a thread which loops over sigwaitinfo.
- monocasa 3y ago> That's the idea anyway. But you can also `kill -SEGV $SOMEPID`. I can also `int 14` with the right hardware permissions and from software to manually invoke a page fault exception. That's how `int 3` works as a breakpoint.
- adonovan 3y agoThis is a useful classification. With the benefit of hindsight--and threading--it would be nice if async signals could just go away, since the kernel can send a notification message to the application over a file descriptor (see man signalfd(2)) and the application can have a dedicated thread to deal with it at its leisure. That leaves the synchronous signals, which are the kernel's way of telling you that you executed a bad instruction and giving you a chance to do something awfully clever instead of crashing.