For delivering a signal, Mach forwards an msg_sig_post message from the invoker of kill to the target process. The target process' signal thread job is it to listen to such messages and to set up signal handler contexts in other threads.

IRC, freenode, #hurd, 2011-04-20

<braunr> bugs around signals are very tricky
<braunr> signals are actually the most hairy part of the hurd
<braunr> and the reason they're aynchronous is that they're handled by a
  second thread
<braunr> (so yes, every process on the hurd has at least two threads)
<svante_> braunr: How to solve the asynch problem then if every process has
  two threads?
<braunr> the easiest method would be to align ourselves on what most other
  Unices do
<braunr> establish a "signal protocol" between kernel and userspace
<braunr> with a set of signal info in a table, most likely at the top of
  the stack
<braunr> but this is explicitely what the original Mach developers didn't
  want, and they were right IMO
<braunr> having two threads is very clean, but it creates incompatibilites
  with what POSIX requires
<braunr> so there might be a radical choice to make here
<braunr> and i doubt we have the resources to make it happen
<svante_> What is the advantage of having two threads per process, a per
  the original design?
<braunr> it's clean
<braunr> you don't have to define async-signal-safe functions
<braunr> it's like using sigwait() yourself in a separate thread, or
  multiplexing them through signalfd()
<svante_> Regardless of the advantages, isn't two threads per process a
  waste of resources?
<braunr> sure it is
<braunr> but does it really matter ?
<braunr> mach and the hurd were intended to be "hyperthreaded"

multithreading.