Re: Improving Shepherd

[Jelle Licht <jlicht@fsfe.org>]

Ludovic Courtès <ludo@gnu.org> writes:

> Heya,
>
> Jelle Licht <jlicht@fsfe.org> skribis:
>
>> Good news: signfalfd seems to work as far as I can see. I am 
>> not quite sure
>> how to make it work consistently with guile ports yet though.
>
> Good!  What do you mean by “work with guile ports” though?
>

It seems that I am running into problems with the way guile 
handles
signals atm. As far as I understood the good people of #guile on
freenode, guile handles signals with a separate thread that 
actually
makes sure signal handling is done at the 'right' time. As such, 
it
seems that there is no easy way to set the mask of blocked signals 
for
all guile threads.

My approach was to wrap `pthread_sigmask' (initially 
`sigprocmask') icw
a call to `signalfd', but it seems that "my" guile thread only 
receives
the signal about ~two-thirds of the time. This only happens when
triggering the signal via 'external' means, such as the kill 
command.
Using the `raise' function from within my guile repl/program did 
always
reliably trigger events coming in on my signalfd based port.

Without being able to block all relevant signals via 
`pthread_sigmask'
from the other guile threads, it seems very difficult to reliably 
use
signalfd based ports to handle signals. Some (ugly) code at [1]
demonstrates this: run the guile script, and find the pid of the 
guile
process via `pgrep', and then send a SIGCHLD signal via `kill -17
<pid>'. You should still see the signal handler for the supposedly
blocked signal be triggered.

tl;dr: I cannot seem to block signals from being handled by guile 
in
some way, which to me seems a prerequisite for using 
signalfd-based
signal handling. My uneducated guess is that guile needs to 
support a
way to set signal masks for all threads in order to deal with 
this.


>> To make use of signalfd, one normally masks signals so that 
>> these can
>> handled via signalfd instead of the default signal handlers; 
>> any process
>> forked start out with the same signal mask, so we would need to 
>> make
>> sure to either reset the signal mask for spawned processes.
>
> Right, we could do that in ‘exec-command’, which is the central 
> place
> for fork+exec.

Right, this does not seem as difficult as I initially thought. If 
the
earlier things I mentioned are resolved/worked around, this should 
be
easy to implement.
>
> Well, let us know what to do next, then!  :-)
>
> Ludo’.

-Jelle

[1]: https://paste.debian.net/1010454/