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

Previous Next

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: Tue, 26 May 2020 23:32:39 +0200

Hello,

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

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

It’s not really possible in practice.  What happens occasionally if you
do that is:

  1. thread A exits ‘select’ due to read event on the signal FD
  2. thread B runs handler
  3. thread A attempts to read from signal FD, which blocks indefinitely
     because the signal is no longer “pending”

> When I read 
>
> "already X>1 threads running, disabling 'signalfd' support"
>
> I would already have to understand why this is ("I didn't start any
> threads, what is going on").

You mean you as a user?  The message is meant as a hint for developers
if they have to debug the thing.  It’s true that there’s nothing users
can do about it.  (But hopefully nobody will see that message, it’s not
supposed to happen when running ‘shepherd’ directly!)

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

I don’t think the *user* manual should document POSIX signal handling in
multi-threaded programs with Linux’ signalfd and with Guile.  That’s a
pretty niche topic that users probably don’t want to know about.  :-)

Those who do want to know about it are Shepherd developers, and I
thought they’d quickly stumble upon the comment if they have to fiddle
with this.  Hopefully the explanation makes it look a bit less arcane!

Thanks,
Ludo’.

Previous Next

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