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

Previous Next

Full log

Message #20 received at 41507 <at> debbugs.gnu.org (full text, mbox):

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

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

>> 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.

Being able to use both sigaction-based handlers and signalfd is simply
weird, not forbidden.

When I read 
--8<---------------cut here---------------start------------->8---
"already X>1 threads running, disabling 'signalfd' support"
--8<---------------cut here---------------end--------------->8---

I would already have to understand why this is ("I didn't start any
threads, what is going on").

Your inline comment clearly indicates some possible approaches to debug
this warning. Knowing that I should call this before any sigaction stuff
seems relevant enough to be documented. The Texinfo manual could have a
(tiny) section on this. The _only_ way to learn this is by
already being a Guile-guru, or by reading the source.

- Jelle

Previous Next

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