Ludovic Courtès <l...@gnu.org> writes:
Heya,
Jelle Licht <jli...@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/
