Re: console-client signal handling

[Roland McGrath]

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