I have a pthread that runs in a loop, calling accept() in a blocking manner. Is there any way to interrupt that call from another thread? Everything points to sending the thread a signal, but apparently you can only send a process a signal.
I can't just kill the thread because then it leaves the socket open. And that's not very clean anyway. Is there really no way to do this?
You can signal a thread using pthread_kill(3).
The pthread_kill() function sends the signal sig to thread, another
thread in the same process as the caller.
If a signal handler is installed, the handler will be invoked in the
thread thread.
Note, you don't have to kill the thread; you can send a signal that simply makes accept fail with EINTR.
Either use select(), or send the singal to the process (this will be a problem if you just want to interupt one of the threads).
Related
My application is sometimes terminating from SIGIO or SIGUSR1 signals even though I have blocked these signals.
My main thread starts off with blocking SIGIO and SIGUSR1, then makes 2 AIO read operations. These operations use threads to get notification about operation status. The notify functions (invoked as detached threads) start another AIO operation (they manipulate the data that has been read and start writing it back to the file) and notification is handled by sending signal (one operation uses SIGIO, the other uses SIGUSR1) to this process. I am receiving these signals synchronously by calling sigwait in the main thread. Unfortunately, sometimes my program crashes, being stopped by SIGUSR1 or SIGIO signal (which should be blocked by a sigmask).
One possible solution is to set SIG_IGN handlers for them but this doesn't solve the problem. Their handlers shouldn't be invoked, rather should they be retrieved from pending signals by sigwait in the next iteration of the main program loop.
I have no idea which thread handles this signal in this manner. Maybe it's the init who receives this signal? Or some shell thread? I have no idea.
I'd hazard a guess that the signal is being received by one of your AIO callback threads, or by the very thread which generates the signal. (Prove me wrong and I'll delete this answer.)
Unfortunately per the standard, "[t]he signal mask of [a SIGEV_THREAD] thread is implementation-defined." For example, on Linux (glibc 2.12), if I block SIGUSR1 in main, then contrive to run a SIGEV_THREAD handler from an aio_read call, the handler runs with SIGUSR1 unblocked.
This makes SIGEV_THREAD handlers unsuitable for an application that must reliably and portably handle signals.
The signal mask can be set on a per thread basis, but what about signal handles? If I call sigaction() before creating new threads with pthread_create(), will the new threads get the same signal handler? What if I use sigaction() after pthread_create(), will that change the entire process signal handlers or just the ones of the thread?
There is only ONE signal handler per process. So threads are not relevant in any kind here. The signal handler is called in the thread context which receives the signal. Which thread receives the signal is not specified if multiple threads have not blocked the signal.
You have to take care if multiple threads waits in system calls. Also you have to take care with using timer actions and calls to sleep.
You may also find this answer helpful: POSIX threads and signals
I have trouble dealing with signal handling in my multithreaded server. I create one thread per connection but I want to have an option to terminate the server with SIGINT. However, things get nasty when one of the threads catches the signal. Is there a way I could block the threads from getting the signal except for the main thread?
A thread inherits its signal mask from the thread creating it.
Assuming the creating thread is the "main" thread, you might like to block all signals in question prior to creating a thread and after the code is done with this unblock the signals in the creating thread.
To modify a thread's signal mask POSIX defines pthread_sigmask().
Update:
When signal handling needs to be performed on a regular base in a multithreaded environment, an interesting approach is to delegate all signals to a separate thread doing nothing else but waiting for signals to arrive using sigwait().
To do so:
Set the signal mask as per the signals you want to handle using pthread_sigmask() in the "main" thread prior to anything else.
Then create the thread to handle the signals.
Then block all signals from 1. in the "main" thread by using pthread_sigmask() again.
And finally create all other threads.
The result would be that all signals specified under 1. would go to the thread created under 2.. All other threads would not receive any of the signals specified under 1..
pthread_sigmask() is exactly what you need. Allow SIGINT processing only in a thread that is supposed to catch this signal.
I have a test case where there are threads spawned using CLONE_THREAD option in clone() .Here if i want to kill a particular thread I suppose we should be using SYS_tgkill in systemcall(). But will the kill actually affect a thread if it is waiting in kernel space(say a futex_wait)?
I tried killing a thread created in the above manner.But when SIGKILL is sent to the same the whole process is getting killed.Am i missing something in using syscall(SYS_tgkill,pid,tid,9) ?
SIGKILL always kills the target process. There is no way around this; it's unblockable, unignorable, and uncatchable.
You could try sending another signal (like SIGUSR1 or SIGHUP or SIGRTMIN) and having a signal handler installed that calls pthread_exit (but note that this function is not async-signal-safe, so you must ensure that the signal handler did not interrupt another async-signal-unsafe function) or use cancellation (pthread_cancel) to stop the blocked thread.
This should work for normal blocking operations (like waiting for data from a pipe or socket), but it will not help you if the thread is in an uninterruptable sleep state (like trying to read from a badly scratched CD or failing hard disk).
Assume a multi-threaded application, with a signal handler defined in it.
Now if a signal is delivered to the PROCESS, and signal handler is invoked - My doubt is what happens to other threads during the period signal handler is running. Do they keep running, as if nothing has happened or they are suspended for that period .. or ...?
Also if someone can tell me WHY to justify the answer?
The specification is pretty clear how signals and threads interact:
Signals generated for the process shall be delivered to exactly one of those threads within the process which is in a call to a sigwait() function selecting that signal or has not blocked delivery of the signal.
As the signal is delivered to exactly one thread, other threads are unaffected (and keep running).
The threads are independent: a signal from one thread to a second thread will not affect any of the others. The why is because they are independent. The only reason why it would affect the others is if the signal handler of the thread in question somehow interacts with other threads.