unofficial mirror of bug-guix@gnu.org 
 help / color / mirror / code / Atom feed
From: ludo@gnu.org (Ludovic Courtès)
To: Mark H Weaver <mhw@netris.org>
Cc: Alex Vong <alexvong1995@gmail.com>, 29826@debbugs.gnu.org
Subject: bug#29826: nondeterministic Broken pipe
Date: Tue, 02 Jan 2018 23:17:08 +0100	[thread overview]
Message-ID: <874lo3ykgr.fsf@gnu.org> (raw)
In-Reply-To: <87inckxetr.fsf@netris.org> (Mark H. Weaver's message of "Tue, 02 Jan 2018 14:04:16 -0500")

Hello,

Mark H Weaver <mhw@netris.org> skribis:

> ludo@gnu.org (Ludovic Courtès) writes:

[...]

>> Not sure!  We specifically ignore EPIPE in cases where it matters, such
>> as for the output of ‘guix package --search’, ‘guix package -A’, etc.
>> In other cases, it’s probably an error, so it’s worth reporting.
>>
>> WDYT?
>
> I see from the comment in (guix ui) where SIGPIPE is ignored, the
> rationale:
>
>   ;; Ignore SIGPIPE.  If the daemon closes the connection, we prefer to be
>   ;; notified via an EPIPE later.
>   (sigaction SIGPIPE SIG_IGN)
>
> Instead of unconditionally ignoring SIGPIPE here in (initialize-guix),
> it might be better to ignore SIGPIPE only if we open a connection to the
> daemon with the intent of mutating the store, and perhaps in some other
> cases where we're mutating information on disk (e.g. switching
> generations).  In those cases, we have a job to do that should ideally
> be completed regardless of whether anyone is still listening to our
> STDOUT.
>
> However, in many other cases, we don't mutate anything on disk, and our
> *only* job is printing information to the user, e.g. when showing
> version/usage information, the list of available packages, the list of
> generations, etc.  In those cases, I think it would be better to let
> SIGPIPE kill us, because there is no reason to keep the 'guix' process
> alive if its output is going nowhere.  These are also the cases where
> it's most useful to pipe 'guix' output into other commands.
>
> So, I think we should consider removing (sigaction SIGPIPE SIG_IGN) from
> (initialize-guix), and instead putting it in various other selected
> places.
>
> What do you think?

Why not.  An option would be to move (sigaction SIGPIPE SIG_IGN) to
‘open-connection’, though that’s not following “library design best
practices.”

If we do that, can we really remove the ‘leave-on-EPIPE’ uses that we
have in (guix scripts package) for instance?  At first sight they are in
‘process-query’, which corresponds to operations that don’t rely on the
store, so that should be safe.

There are a few other uses of ‘leave-on-EPIPE’ that happen while the
store is opened (in ‘guix size’, ‘guix challenge’).  We’d have to keep
these.

Thoughts?

Ludo’.

  reply	other threads:[~2018-01-02 22:18 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-23 20:23 bug#29826: nondeterministic Broken pipe Alex Vong
2017-12-23 20:48 ` Andreas Enge
2017-12-24  8:37   ` Alex Vong
2017-12-24 22:11 ` Mark H Weaver
2017-12-25 14:02   ` Alex Vong
2017-12-31 10:11     ` Ludovic Courtès
2018-01-02 12:07       ` Alex Vong
2018-01-02 19:04       ` Mark H Weaver
2018-01-02 22:17         ` Ludovic Courtès [this message]
2018-02-14 12:21 ` Oleg Pykhalov

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=874lo3ykgr.fsf@gnu.org \
    --to=ludo@gnu.org \
    --cc=29826@debbugs.gnu.org \
    --cc=alexvong1995@gmail.com \
    --cc=mhw@netris.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).