The POSIX.1 behavior is that a process signal gets handled by any thread that isn't blocking that signal. A new thread inherits the blocked signal set from the thread that called pthread_create.
The Hurd signal implementation predates the 1996 POSIX specification that invented this behavior. In the current Hurd libc, things are quite different. A process signal goes to one particular Mach thread (_hurd_sigthread); this starts out being the initial thread (the one that runs `main'), and there is actually no available interface for changing it. If the initial thread dies, no signal handlers will get run. Furthermore, the signal handler state set by `sigaction' is per-thread rather than shared by the whole process (new threads start with a copy of the initial thread's state). This is all quite flaky and constitutes much of those "known reasons Roland wants to rewrite signal support one of these days" you might have heard about. ;-) But, it does mean that it is pretty easy to make a multithreaded server cope reasonably with signals and do it in a way that will continue to work when real pthreads with full signal integration exist one day. That is, have the main thread just do pause/sigsuspend forever rather than offering itself as a server work thread. The slick way to do this is that you early on (before any pthreads could have been created) block in the main thread the signals you want to handle, so that all pthreads inherit that blocked state, and then have the main thread call sigsuspend to unblock them for itself after threads have been created. That will work fine now, and will work fine with proper POSIX.1 pthread semantics. Thanks, Roland _______________________________________________ Bug-hurd mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/bug-hurd
