For delivering a signal, Mach forwards an
msg_sig_post message from the
kill to the target process. The target process'
job is it to listen to such messages and to set up signal handler contexts in
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"