unofficial mirror of guix-patches@gnu.org 
 help / color / mirror / code / Atom feed
From: Jelle Licht <jlicht@fsfe.org>
To: "Ludovic Courtès" <ludo@gnu.org>
Cc: 41507@debbugs.gnu.org
Subject: [bug#41507] [PATCH Shepherd 0/2] Use 'signalfd' on GNU/Linux
Date: Mon, 25 May 2020 10:02:07 +0200	[thread overview]
Message-ID: <87mu5wv3wg.fsf@jlicht.xyz> (raw)
In-Reply-To: <87tv04wjm9.fsf@gnu.org>

Ludovic Courtès <ludo@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








  reply	other threads:[~2020-05-25  8:03 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-24 14:27 [bug#41507] [PATCH Shepherd 0/2] Use 'signalfd' on GNU/Linux Ludovic Courtès
2020-05-24 14:36 ` [bug#41507] [PATCH Shepherd 1/2] system: Add support for 'signalfd' Ludovic Courtès
2020-05-24 14:37   ` [bug#41507] [PATCH Shepherd 2/2] shepherd: Use 'signalfd' when possible Ludovic Courtès
2020-05-25 12:31     ` Mathieu Othacehe
2020-05-26 22:13       ` bug#41507: " Ludovic Courtès
2020-05-27  5:45         ` [bug#41507] " Jan Nieuwenhuizen
2020-05-27  9:23           ` Ludovic Courtès
2020-05-30 17:44       ` Ludovic Courtès
2020-06-02  7:00         ` Mathieu Othacehe
2020-06-02 21:38           ` Ludovic Courtès
2020-05-24 15:13 ` [bug#41507] [PATCH Shepherd 0/2] Use 'signalfd' on GNU/Linux Jelle Licht
2020-05-25  7:37   ` Ludovic Courtès
2020-05-25  8:02     ` Jelle Licht [this message]
2020-05-26 21:32       ` Ludovic Courtès

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87mu5wv3wg.fsf@jlicht.xyz \
    --to=jlicht@fsfe.org \
    --cc=41507@debbugs.gnu.org \
    --cc=ludo@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).