Home › Blogs › daper's blog ›

All about Linux signals

Submitted by daper on Tue, 02/03/2009 - 00:33

Signals and threads


There are differences in signal handling between a single-threaded program and a multi-threaded program. Since according to POSIX specification a multi-threaded program is one process with one PID, which thread is interrupted to handle the arriving signal? If you use the old (unsupported) LinuxThreads implementation the answer is simple: all threads have separate PIDs, so the signal is delivered to the thread with PID provided to kill(2), so in case of this implementation all threads are treated as separate processes. This fact is not really interesting since this implementation is not used in any modern Linux distribution.

With Native POSIX Threads Library things get more interesting. Since this is the POSIX compliant implementation the behavior described here also applies to other POSIX systems.

Which thread receives the signal?


This is the most interesting question. There are two cases:
  • Process-directed signals (sent to a PID using functions like kill(2)). Threads have their separate signal mask which can be manipulated using pthread_sigmask(2) similary to sigprocmask(2), so such signal is not delivered to a thread that has this signal blocked. It's delivered to one of threads in the process with this signal unblocked. It's unspecified which thread will get it. If all threads have the signal blocked, it's queued in the per-process queue. If there is no signal handler defined for the signal and the default action is to terminate the process with or without dumping the core the whole process is terminated.
  • Thread-directed signals. There is a special function to send a signal to a specific thread: pthread_kill(2). It can be used to send a signal from one thread to another (or itself). This way the signal will be delivered or queued for the specific thread. There are also per-thread directed signals generated by the operating system like SIGSEGV. If there is no signal handler defined for a signal that default's action is to terminate the process, a thread-directed signal terminated the whole process.

As you can see there is a process-wide signal queue and a per-thread queues.

Signal handlers


Signal actions are set for the whole process. The behavior of signal(2) is undefined for multi-threaded application, sigaction(2) must be used. Keep in mind that none of pthreads related functions are described as signal safe in signal(7). Especially using mutexes in signal handlers is very bad idea.

sigwaitinfo()/sigtimedwait() and process-directed signals


To get sigwaitinfo(2) and sigtimedwait(2) functions behave reliable for process-directed signals, all signals you wait for must be blocked for all threads. Especially using pause() for process-directed signals can be a bad idea.

Real-time signals


As previously said, both threading implementations (LinuxThreads and NPTL) internally use some number of real-time signals, so it's another good reason to always refer to those signals using SIGRTMIN+n notation.

Comments

Restarting system calls

Submitted by Anonymous on Fri, 04/13/2012 - 23:57.
"It's not specified which calls are restarted" - says the last paragraph. It is very much specified, on the signal(7) man page.

very useful and readable blog about Unix signals

Submitted by Anonymous on Mon, 03/26/2012 - 21:48.
Unix signals is a deep and interesting topic. For example, the signal() function is either referring to the version in the C library or the version in the operating system. The topic of signals has a rich history as part of Unix.

Thanks

Submitted by Anonymous on Thu, 09/22/2011 - 08:09.
I just want to say thank you , I was googling about what happens to signals handlers when I fork() and you blog showed up. thanks

Ctrl+Z Signal

Submitted by Anonymous on Fri, 01/21/2011 - 08:16.
CTRL-Z - sends SIGTSTP

Hi, typo jerk here

Submitted by Anonymous on Sat, 11/07/2009 - 16:51.
Hi, typo jerk here again: page3: Moreover, it lack's features -> lacks why the signal was send -> sent page5: signals like SIGPIPE, SIGUSR1, SIGUSR1 -> SIGUSR2 signal i exits -> it This program read from it's -> reads, its Additionally when SIGUSR1 -> Additionally, when [missing comma] I hope you really, truly don't consider this as some kind of personal attack.

i love type jerk!

Submitted by Anonymous on Mon, 04/09/2012 - 06:41.
typos suck! combat them!

Thanks. I don't consider it

Submitted by daper on Sun, 11/29/2009 - 18:29.
Thanks. I don't consider it as an attack :) Some of them are just caused by the fact that English is not my native language.

I was looking for linux

Submitted by Anonymous on Thu, 08/27/2009 - 01:27.
I was looking for linux programming tutorial and i found this blog . keep good work.

Great write-up

Submitted by mattismyname (not verified) on Thu, 08/06/2009 - 17:22.
Great write-up; thanks for the information.

Signals - That's not everything

Submitted by Anonymous on Tue, 04/07/2009 - 15:39.
I wouls suggest the reading of "Advanced Programming in the Unix Environment". It does not address signals with threads, but it is the most extensive explanation of signal handling. It treats also long jumps to remove races in signal handling.

Problem regarding signals.

Submitted by Anonymous on Tue, 02/01/2011 - 08:38.
Hi I have written a sample program to understand signal handling. signal1.c 
#include 
#include 
/* for random() stuff */
#include 
#include 
#include 
#include 

void
termination_handler (int signum)
{
  struct temp_file *p;
 int err;
  printf("\nTerminated\n");
		sleep(10); 
}

int
main (void)
{

	int shmfd,*shared_msg, pid;
	struct sigaction new_action, old_action;
	int shared_seg_size = (1 * sizeof(int));
	//shm operations
	shmfd = shm_open("/shm_sumit",O_CREAT|O_RDWR|O_EXCL,S_IRWXU | S_IRWXG);
	if (shmfd < 0) {
	        perror("In shm_open()");
        	exit(1);
    	}

	ftruncate(shmfd, shared_seg_size);
	shared_msg = (int *)mmap(NULL, shared_seg_size, PROT_READ | PROT_WRITE, MAP_SHARED, shmfd, 0);
	if (shared_msg == NULL) {
	        perror("In mmap()");
        	exit(1);
    	}

        pid = getpid();
        *shared_msg = pid; 

  /* Set up the structure to specify the new action. */
  new_action.sa_handler = termination_handler;
  sigemptyset (&new_action.sa_mask);
  new_action.sa_flags = SA_NODEFER;

    sigaction (SIGUSR1, &new_action, NULL);
     //while(1)
{
   sleep(10);
}
	/*if (shm_unlink("/shm_sumit") != 0) {
	        perror("In shm_unlink()");
        	exit(1);
    	}*/

}



signal2.c


#include 
#include 
#include 
void
termination_handler (int signum)
{
  struct temp_file *p;
  printf("\nTerminated");
}

int
main (void)
{
	int shmfd,*shared_msg, pid;
    struct sigaction new_action, old_action;
    int shared_seg_size = (1 * sizeof(int));
    //shm operations
    shmfd = shm_open("/shm_sumit",O_RDWR,S_IRWXU | S_IRWXG);
    shared_msg = (int *)mmap(NULL, shared_seg_size, PROT_READ | PROT_WRITE, MAP_SHARED, shmfd, 0);
    printf(" Process id of sigtest1 = %d\n",*shared_msg);
 kill(*shared_msg,SIGUSR1);
 kill(*shared_msg,SIGUSR1);
 kill(*shared_msg,SIGUSR1);
 kill(*shared_msg,SIGUSR1);
 kill(*shared_msg,SIGUSR1);
	
	sleep(1);
	if (shm_unlink("/shm_sumit") != 0) {
        perror("In shm_unlink()");
        exit(1);
    }

}
here sigtest2.c send SIGUSR1 to sigtest1.c 5 times, but the string "Terminated " gets printed sometimes 2 times and sometimes 5 times. why is this printing behavior inconsistent??

Hi, because while handling

Submitted by Anonymous on Fri, 05/25/2012 - 08:37.
Hi, because while handling the signal it wont be handle the signal of same type . you can check this by remove the sleep(10) in sigtest1.c . It will work fine.

RSS feeds

Syndicate content