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’.
next prev parent 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).