-----BEGIN PGP SIGNED MESSAGE-----
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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.1 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.5 and Gnu Privacy Guard <http://www.gnupg.org/>
-----END PGP SIGNATURE-----
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Jun 07 2000 - 21:00:13 EST