GNU bug report logs - #41507
[PATCH Shepherd 0/2] Use 'signalfd' on GNU/Linux

Previous Next

Package: guix-patches;

Reported by: Ludovic Courtès <ludo <at> gnu.org>

Date: Sun, 24 May 2020 14:28:01 UTC

Severity: normal

Tags: patch

Done: Ludovic Courtès <ludo <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Ludovic Courtès <ludo <at> gnu.org>
To: Jelle Licht <jlicht <at> fsfe.org>
Cc: 41507 <at> debbugs.gnu.org
Subject: [bug#41507] [PATCH Shepherd 0/2] Use 'signalfd' on GNU/Linux
Date: Mon, 25 May 2020 09:37:18 +0200
Hi Jelle,

Jelle Licht <jlicht <at> fsfe.org> skribis:

> I am extremely happy to see that you got this to work; I bashed my head
> against a wall getting the signal-handling thread to block the right
> signals. This does seem like something that should be in guile proper
> rather than shepherd though.

Oh right, you had first-hand experience fiddling with this!

Yeah ideally Guile would provide some ‘signalfd’ support.  I’m not sure
exactly how that should work.  It’s easier to have ad-hoc support in the
Shepherd in the meantime.

> As I read it, you need to set up a signalfd handlers for specific
> signals before ever calling `sigaction'. Does this not have an impact on
> being able to do some forms of REPL-driven development with shepherd?

It depends, I don’t test things like SIGCHLD handling from the REPL
anyway.  :-)

> Perhaps it makes sense to document this gotcha (and some of its
> implications) in a location other than an inline comment in
> `maybe-signal-port'.

Where would you document that?  Currently, one gets a warning if signals
cannot be properly blocked.

Thanks for your feedback!

Ludo’.




This bug report was last modified 4 years and 349 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.