Multi-thread && CTRL+C

Hello all,
When a CTRL-C signal to a porcess with multi-tread,
1) do all the threads will be received the SIGINT
2) or only the main thread can receive it?
3) or only the one random thread can receive it?

Could you give me some feedbacks?
Any comments or advice are welcome.

thanks

This is a little complicated to answer. Since you are posting in the non-*NIX Forums under Programming, I won't presume you are asking about any particular OS.

There are many varieties of "threads", ranging from very low level hardware supported threads, to high-level language thread libraries.

Basically, in *nix, signals are delivered to proceses by the kernel - it essentially sets up conditions so that a process' signal handler is called upon return from the kernel. On a single CPU machine, this idea is trivial (but there are complexities in the implementation which are a challenge to solve correctly), as only one process can be running. If the kernel itself is currently running, it selects which process will run next, so no troubles here. And it is not too different if there are multiple threads (which you should just think of as very light-weight processes). Only one will be on a single-CPU system at a time, and which one is at the kernel's control.

A random approach may not be good, because it might be critical that all threads in a process stop as soon as possible. But in some environments, one ore more threads can be killed, while the others continue on until their time limit has been reached.

A system can forcibly yank a thread from a CPU to deal with a signal immediately. I can also do likewise in multi-CPU systems.

Now the real challenge is when there are multiple CPUs and multiple threads. On some systems, all threads are called into the interrupt or signal check block, and one places a semaphore around the sensitive data structures,and goes off to handle the signal. The others eventually pass through finding nothing to do, and they return back to their running states.

There are all sorts of variants. Some systems can give affinity to a given thread, wherein it handles signals.

What you have to do is look at the various signal/kill related documents for the target OS, to see how they handle signals.

Let me add to what has been said, thus far. I will assume you are talking about Mutli-threaded C programming on Linux machine. You will find answers to your questions in the man pages; refer to these docs as a starter.
a. $ man signal
b. $ man 7 signal
c. $ man sigaction
d. $ man sigwaitinfo
e. $ man sigfillset
f. $ man pthread_sigmask
g. $ man pthread_create

The GLIB library may also contain information on utilities to aid multi-threaded application and gui application development. I also make available via the following link a template C program for creating a daemon (which communicate using signals) for you review: http://mysite.verizon.net/skoona/sit...-0.1.4.tar.bz2

The above link contains source for three programs; daemon_glib, daemon_libc, and daemon_info. They are examples or starter program shells that I use to start new daemon programs. They include a signal management structures for multi-threaded program as the best feature, and are fairly complete.

To outright answer your questions: It depends!

If you take no signal management action then all signals are enabled and will be delivered to the first thread in the process as the norm. In the case where the thread/process did something to cause the signal - that thread will be the target for the system signal; in all other cases any thread could receive a signal unless that thread/process explicitly blocks that signal(s).

What signal management methods are considered best practices? Again it depends!

I design-in a signal management plan for each program and implement that plan very carefully. Typically, the main process thread sets a block on all signals using sigfillset() and pthread_sigmask(). Then a thread designed to manages signal communication for the program is initiated. This sig_thread initially inherits the ALL_BLOCKED signal state from the main thread, so the first thing it does in UNBLOCK all signals (making itself the target for all signals) for its thread with sigfillset() and pthread_sigmask() management. It then immediately goes into a synchronous (blocked) i/o wait on any and all incoming signals for the whole process/appplication by using sigwaitinfo(). On each return from sigwaitinfo() the signal is processed with appropriate actions taken and it returns to wait on the next signal.

Note signals that were/are blocked may be held or queued by the OS until any thread unblocks that signal; so there are not always lost or missed.

There are lots of issues with multi-threaded programming managing signals is one of the easier ones. Just remember to limit your application processing while inside the signal handling thread. I never do much more than set a application control flag or boolean while inside a signal handler.

The biggest issue I find with multi-threaded programming is thread synchronization, or how to make the threads wait without polling, and remembering which C library api is thread-safe.

James,

Nice answer Skoona.

If you have a moment, take a look at this guy's thread. His app is not catching SIGRTMINx signals, and isn't sure why, despite installing a sig handler.

http://www.linuxquestions.org/questi...rmally-653952/

thanks, I posted to the other thread -- thats an interesting one.

James,

Hello skoona,Mr. C.,

Thank you very much .

Now I am working on some issue about the relationship of signal and multi-thread .

From your replay, I have some new idea and "tricks" for my application test .

Thanks again.

Originally Posted by Alexlun Now I am working on some issue about the relationship of signal and multi-thread .

Take a look at this code. Its my starter code template for creating daemons. It contains a comprehensive signal handler baseline for working with signals from multi-threaded daemons.

http://mysite.verizon.net/skoona/sit...-0.1.4.tar.bz2

James,

Nice skoona，you are amaing,special thanks.