4 ms·
Also, signals become much easier to deal with if your program is single-threaded. Once threads get involved, it becomes more complex to know which thread(s) wil
by breadbox 10y ago
Also, signals become much easier to deal with if your program is single-threaded. Once threads get involved, it becomes more complex to know which thread(s) will receive a given signal.
- signa11 10y ago> Once threads get involved, it becomes more complex to know which thread(s) will receive a given signal. well, one approach that might be worth looking into would be to designate a special thread as a signal-handling-only thread. others just block every signal that can possibly be blocked. this signal-handling-thread then communicates the signals etc. to others as needed. prima-facie, this boils down to signal handling for single threaded programs. what might be the downsides ?
- scottlamb 10y agoPeople say "signals" as if they're just one thing, but I find it more useful to break them into two categories: * process-directed signals such as SIGHUP, SIGINT, SIGWINCH, SIGTERM, SIGQUIT, SIGCHLD. They come from outside the process, including the `kill` command, the init system, and the terminal. For these, a dedicated signal-handling thread is a common, practical approach. Even if your program is single-threaded before implementing signal handling, creating a new thread might be the best approach. Or you could integrate signal handling with an event loop via the self-pipe trick. * thread-directed signals such as SIGSEGV, SIGFPE, SIGBUS (the preceding are all machine exceptions), SIGPIPE, SIGPROF, or anything sent by pthread_kill / pthread_sigqueue. If you need to handle these signals (usually for diagnostics), by definition you have to do it in the thread in question. And you almost certainly need a traditional signal(2) / sigaction(2) style signal handler.