From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jelle Licht Subject: Re: Improving Shepherd Date: Thu, 15 Feb 2018 18:05:43 +0100 Message-ID: <871shmji8o.fsf@fsfe.org> References: <871si8bc5g.fsf@zancanaro.id.au> <877errn23f.fsf@zancanaro.id.au> <871shzeg8m.fsf@gnu.org> <87a7wbu2ht.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:42733) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1emMyy-0004di-Ll for guix-devel@gnu.org; Thu, 15 Feb 2018 12:06:05 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1emMyx-0001WK-Eb for guix-devel@gnu.org; Thu, 15 Feb 2018 12:06:04 -0500 In-reply-to: <87a7wbu2ht.fsf@gnu.org> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Ludovic =?utf-8?Q?Court=C3=A8s?= Cc: guix-devel Ludovic Court=C3=A8s writes: > Heya, > > Jelle Licht skribis: > >> Good news: signfalfd seems to work as far as I can see. I am=20 >> not quite sure >> how to make it work consistently with guile ports yet though. > > Good! What do you mean by =E2=80=9Cwork with guile ports=E2=80=9D thou= gh? > It seems that I am running into problems with the way guile=20 handles signals atm. As far as I understood the good people of #guile on freenode, guile handles signals with a separate thread that=20 actually makes sure signal handling is done at the 'right' time. As such,=20 it seems that there is no easy way to set the mask of blocked signals=20 for all guile threads. My approach was to wrap `pthread_sigmask' (initially=20 `sigprocmask') icw a call to `signalfd', but it seems that "my" guile thread only=20 receives the signal about ~two-thirds of the time. This only happens when triggering the signal via 'external' means, such as the kill=20 command. Using the `raise' function from within my guile repl/program did=20 always reliably trigger events coming in on my signalfd based port. Without being able to block all relevant signals via=20 `pthread_sigmask' from the other guile threads, it seems very difficult to reliably=20 use signalfd based ports to handle signals. Some (ugly) code at [1] demonstrates this: run the guile script, and find the pid of the=20 guile process via `pgrep', and then send a SIGCHLD signal via `kill -17 '. 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=20 in some way, which to me seems a prerequisite for using=20 signalfd-based signal handling. My uneducated guess is that guile needs to=20 support a way to set signal masks for all threads in order to deal with=20 this. >> To make use of signalfd, one normally masks signals so that=20 >> these can >> handled via signalfd instead of the default signal handlers;=20 >> any process >> forked start out with the same signal mask, so we would need to=20 >> make >> sure to either reset the signal mask for spawned processes. > > Right, we could do that in =E2=80=98exec-command=E2=80=99, which is the= central=20 > place > for fork+exec. Right, this does not seem as difficult as I initially thought. If=20 the earlier things I mentioned are resolved/worked around, this should=20 be easy to implement. > > Well, let us know what to do next, then! :-) > > Ludo=E2=80=99. -Jelle [1]: https://paste.debian.net/1010454/