[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#29826: nondeterministic Broken pipe
From: |
Ludovic Courtès |
Subject: |
bug#29826: nondeterministic Broken pipe |
Date: |
Tue, 02 Jan 2018 23:17:08 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux) |
Hello,
Mark H Weaver <address@hidden> skribis:
> address@hidden (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’.