The problem of Linux signal processing method

This week a new colleague asked me to look at a signal processing problem, the program wants to exit after receiving a signal, and he does a lot of things in the signal processing, including freeing up some global memory.

So the problem arises, the program hangs dead when the process is uncertain, with GDB, all the threads are hung in the Pthread_once method, and it seems that each thread is processing the signal, where the thread stack that causes the problem is as follows:

Thread 1 (thread 0x7f41252f3720 (LWP 31542)):

#0 0x000000339860cb1b in Pthread_once () from/lib64/libpthread.so.0

#1 0x00000033982fd6f4 in BackTrace () from/lib64/libc.so.6

#2 0x000000339826fa4b in __libc_message () from/lib64/libc.so.6

#3 0x0000003398275366 in Malloc_printerr () from/lib64/libc.so.6

#4 0x0000003398278de4 in _int_malloc () from/lib64/libc.so.6

#5 0x0000003398279b91 in malloc () from/lib64/libc.so.6

#6 0X00007F41253B40BD in operator new (unsigned long) () from/usr/lib64/libstdc++.so.6

More Wonderful content: http://www.bianceng.cnhttp://www.bianceng.cn/OS/Linux/

#7 0x00007f41253b41d9 in operator new[] (unsigned long) () from/usr/lib64/libstdc++.so.6

---Type <return> to continue, or Q <return> to quit---

#8 0x000000000045f86a in Log4cpp::stringutil::vform (char const*, __va_list_tag*) ()

#9 0x000000000044eb69 in log4cpp::category::_logunconditionally (int, char const*, __va_list_tag*) ()

#10 0x000000000044f4af in Log4cpp::category::warn (char const*, ...) ()

#11 0x00000000004431a1 in Singalhandler (int) ()

#12 <signal Handler Called>

#13 0x000000339860cb19 in Pthread_once () from/lib64/libpthread.so.0

#14 0x00000033982fd6f4 in BackTrace () from/lib64/libc.so.6

#15 0x000000339826fa4b in __libc_message () from/lib64/libc.so.6

#16 0x0000003398275366 in Malloc_printerr () from/lib64/libc.so.6

#17 0x0000003398278de4 in _int_malloc () from/lib64/libc.so

What's the problem? It seems that in all open source code, there are few people in the signal processing method to write a lot of code, this is why?

The reason is that the signal is likely to interrupt your thread at any time in the execution code, the signal processing method inserted into the execution, it may cause some functions are repeatedly reentrant. For example, in the above example, Thead1 is a new object, the implementation of malloc allocation of memory, suddenly interrupted by the signal, and signal processing methods incredibly malloc process, and malloc can not be repeated back into! So it leads to death.

Another problem is that the subprocess inherits many of the resources of the parent process, including the signal, and his program processes the signal before pthread_create many of the worker threads, and there is no shielding signal, so all threads are handling the signal processing, and all threads are dead.

There are many solutions, usually in the signal processing method only do a small amount of work, notify other threads to recycle resources.

For multithreaded programming, only one thread uses the blocking signal processing method, the full-time processing signal, this more conforms to the multithreading design spirit. For example, before a child thread is derived, using Pthread_sigmask to set the signal does not interrupt the child thread, while in the main thread, the blocking Sigwait method is used to synchronize the signal, where complex operations can be handled without fear of "reentrant" issues.