Re: emacs23.3 issues and hurd signals

[Roland McGrath]

> However, when compiling the C code, a lot of warnings are issued about
> emacs using depreciated sigblock and sigsetmask functions. The
> recommended function to use now is sigprocmask. 

That is true.  However, there is only an actual difference if there are
more than 32 signal numbers available, and the Hurd has exactly 32.

> However, this function is not thread safe, pthread_sigmask should be used
> instead. 

That is not a very clear way to say it.  In POSIX, sigprocmask is said
to operate on the "the process" and pthread_sigmask on the thread, and
it's not specified what exactly this means sigprocmask does in the
presence of multiple threads (i.e. pthreads).  There is nothing "unsafe"
about sigprocmask in the usual sense of not having requisite locking or
whatever.  It's just that POSIX doesn't say which thread (or threads) it
affects.  In all sane implementations, these are two names for the same
function, and that's how it is in modern GNU/Linux.

Hurd libc does not have pthreads at all (as its implementation predates
their specification).  What it does have is a generally sensible
extension of the pre-pthreads POSIX signal semantics (1003.1-1990) to
multiple Mach threads.  (In the Hurd libthreads library, each cthread is
a single Mach thread.)  What that means here is that sigprocmask applies
to the calling thread.

> However, as discussed with braunr on IRC, he claims that single-threaded
> programs does not have to bother about the mach exception thread running
> in parallel to the main thread.

This thread (an invention of Hurd glibc) is called the "signal thread".
No normal program has to worry about that thread.  It does not have any
POSIX-like semantics associated with it, and you don't normally need to
know it's there.  A "single-threaded" Hurd program has two Mach threads,
the user thread and the signal thread.  A 23-threaded Hurd program has
24 Mach threads, the 23 user threads and the signal thread.  Aside from
the signal-preemptor interface (don't worry about it), no "user" code
ever runs in the signal thread.  That includes the implication that
signal handlers never run in the signal thread (its main purpose is to
control other threads to implement signal handling, so they really
couldn't even if it weren't just a terrible idea).

> 2) Would changing the emacs code to use sigprocmask have the potential
> to make any difference here? Except making the warnings go away.

That seems inordinately unlikely.  If it does make any difference, then
that is a bug in libc.  It's hard to see how it could be, though.
The implementation of sigsetmask is to call sigprocmask.

> 3) In the man page for pthread_sigmask, there is a test example, showing
> that signals could be blocked and handled in a separate thread. However,
> when running that code in GNU/Hurd, the output is not as expected (and
> tested on GNU/Linux!). The code at hand is available at
> http://pastebin.com/43ECGeaq

The Hurd libc does not have POSIX.1-1996 signal semantics as regards
pthreads, since it does not have pthreads.

Both POSIX.1-1996 and Hurd libc semantics are that the blocked signal
set (once called the signal mask, hence the old function sigsetmask) is
per-thread.  What differs is the handling of a process-wide signal (and
also the per-thread meaning of sigaction).  In POSIX.1-1996, such a
signal is handled by any thread that doesn't have that signal blocked
(an unpredictable choice among those qualifying).  In Hurd libc, such a
signal is always handled by the one thread stored in the variable
_hurd_sigthread.  This is initially the main thread, and there is no
public interface to change it.

In Hurd libc, sigaction (i.e. the set of signal handlers) is per-thread.
In POSIX.1-1996, it is process-global.


Thanks,
Roland