Subject: Re: Sempahore on NetBSD work or no ?
To: David Maxwell <david@vex.net>
From: Nathan J. Williams <nathanw@wasabisystems.com>
List: current-users
Date: 01/27/2003 13:49:32
David Maxwell <david@vex.net> writes:

> I was under the impression that POSIX did not require that a signal
> (such as SIGCHLD) be delivered to the thread that it would have, had the
> thread been a process instead (i.e. a thread which called fork()).

That's correct, there is no such requirement. There are all sorts of
difficulties with making that guarantee; for example, the thread may
no longer exist, and it precludes applications that want to use
separate threads for signal handling. What POSIX says is that a signal
may be delivered to any thread that does not have the signal blocked
in its per-thread signal mask. If the programmer wants to arrange to
recieve SIGCHLD in one thread, that can be done by blocking SIGCHLD in
all *other* threads. This requires knowledge and control of all of the
threads, which is non-modular, but signals don't modularize well
anyway.

> In process space, the process that calls alarm(3) will get the SIGALRM.
> In thread space, I thought POSIX said 'any thread can get the SIGALRM',
> and the programmer has to deal with that.

Any thread that doesn't have SIGALRM blocked. 

I'm going to steal some text from David Butenhof's excellent Pthreads
book, describing the goals of the authors of the standard with respect
to signals (from section 6.6):

``There were two primary conflicting goals:

 * First, "signals should be completely compatible with traditional
   UNIX". That means signal handlers and masks should remain
   associated with the process. That makes them virtually useless with
   multiple threads, which is as it should be since signals have
   complicated semantics that make it difficult for threads and
   signals to coexist peacefully. Tasks should be accomplished
   synchronously using threads rather than asynchrousnously using
   signals.
 * Second, "signals should be completely compatible with traditional
   UNIX". This time, "compatible" means signal handlers and masks
   should be completely thread-private. Most existing UNIX  code would
   then function essentially the same running within a thread as
   it had within a process. Code migration would be simplified.

The problem is that the definitions of "compatible" were incompatible.''

        - Nathan