Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

What signals shouldn't be blocked by thread in multi-threaded program in C?

I have a multi-threaded program. I want to handle all meaningful signals in a single thread. That's what I do before creating any thread:

sigset_t signal_set, old_set;

sigfillset(&signal_set);
// What signals should I leave unblocked here?
pthread_sigmask(SIG_SETMASK, &signal_set, &old_set);

std::thread( /* some args */ );

pthread_sigmask(SIG_SETMASK, &old_set, nullptr);

But my good sense suggests leaving some signals unblocked, since there is a plenty of situation when signals may be sent directly to specific thread: SIGSEGV or SIGPROF - I believe, it's as good as leaving unblocked SIGINT in an interactive program.


Are my suggestions correct about those two signals (SIGSEGV, SIGPROF)?

What other signals should I leave unblocked following some common sense?

like image 427
abyss.7 Avatar asked Nov 16 '14 14:11

abyss.7


People also ask

Is it possible to block one thread in a process without blocking the entire process?

If the process has only one thread, then yes. If the process has multiple threads, then normally no if the operating system supports multithreading. This question can also be addressed in terms of the underlying implementation of user threads.

Where should a signal be delivered for multi threaded?

A process-directed signal may be delivered to any one of the threads that does not currently have the signal blocked. If more than one of the threads has the signal unblocked, then the kernel chooses an arbitrary thread to which to deliver the signal.

Are signals thread safe?

Signals2 are thread safe and can be used in multithreaded applications. For example, objects of type boost::signals2::signal and boost::signals2::connection can be accessed from different threads.

Can each thread have its own signal handler?

Each thread can have its own set of signals that will be blocked from delivery. The sigthreadmask subroutine must be used to get and set the calling thread's signal mask.


1 Answers

Asynchronous signals (that's most of them, including anything sent by the kill command/function and signals generated by the controlling terminal like SIGINT) are deliverable to any thread in the process that has the signal unblocked, so there's no need to keep them unblocked in all threads. If you're using a dedicated signal handling thread, you want them blocked in all threads except the signal handling thread.

Synchronous signals on the other hand are delivered to a particular thread as a result of an action by that thread. They include SIGPIPE, SIGBUS, SIGSEGV, SIGFPE, etc. Except for SIGPIPE, none of these should happen at all unless you have serious bugs in your program, and you probably want to block SIGPIPE anyway so you can instead get the EPIPE error and handle this condition properly. So for the most part I would say it doesn't hurt to just block them all. If you really find yourself needing to handle SIGSEGV or such, you probably should rethink the reasons, but in the mean time feel free to unblock it.

like image 58
R.. GitHub STOP HELPING ICE Avatar answered Oct 21 '22 04:10

R.. GitHub STOP HELPING ICE