Re: pthread problem with asynchronous signals

From: Christopher Smith (
Date: Thu Jun 01 2000 - 20:11:38 EST

Hash: SHA1

On Wed, May 24, 2000 at 07:59:01AM -0500, Robert M. Hyatt wrote:
> Signals and threads just don't mix. Signals terminate many system
> calls with EINTR (for example). Multiple threads can receive the
> signal, including every thread _but_ the one you really want to see
> the thing.

Actually, the rules under POSIX are fairly clear. Assuming a signal
was caused by a thread inside a give n process, the signal should be
delivered to that thread. The only case where any of a group of
threads could receive a signal is in the even that an external process
sends a signal to a process using kill. In this case the delivery of
the signal is influenced by the signal masks of each of the threads.
> I've been doing threads for a long time, dating back to Cray's first
> version of Unicos. I found that signals are simply something to be
> completely avoided if threads are being used.

This is not entirely fair. Certainly, lots of things that are done via
signals in single-thread models don't map so well in multi-thread
models (and indeed are better done in the first place using threads
and blocking), but signals have a very valid place in a threaded
environment, if for no other reason than a threaded program should
still be able to respond to SIGINT. ;-)

Certainly it's not easy to provide a good interface to signals in a
threaded environment, but it can and has been done. Linux's
implementation isn't exactly perfect yet, but it's getting there.

- --Chris

Version: GnuPG v1.0.1 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.5 and Gnu Privacy Guard <>


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

This archive was generated by hypermail 2b29 : Wed Jun 07 2000 - 21:00:13 EST