> 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
