bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: tee logs no output if stdout is closed


From: Bruno Haible
Subject: Re: tee logs no output if stdout is closed
Date: Fri, 3 Oct 2008 13:20:10 +0200
User-agent: KMail/1.5.4

Jim Meyering wrote:
> > EPIPE is part of the normal shutdown
> > protocol of pipes, when the pipe writer chooses to block or ignore SIGPIPE.
> 
> First, you're assuming that the pipe writer chooses to
> block or ignore SIGPIPE

Yes, EPIPE only occurs if SIGPIPE is blocked or ignored.

> which is not generally recommended.

Huh? There is no authority that recommends leaving SIGPIPE's handler set to
SIG_DFL. In fact,
  - SIG_DFL is appropriate for programs whose only purpose/effect is to write
    something to standard output and standard error. (The majority of the
    Unix programs.)
  - SIG_IGN is appropriate for programs whose main purpose is to do side 
effects.
  - SIG_IGN is appropriate also when writing into the stdin of child processes
    which may or may not read all the input before exiting. 'msgfilter' is
    such a program.

> Imagine a scenario in which the pipe reader is expected always to
> be reading, and so the pipe writer can expect that any write failure with
> errno==EPIPE indicates the reader has terminated unexpectedly.  With your
> modification, a pipe writer using close_stream would be unable to detect
> a write failure due to EPIPE.

The pipe writer will be the parent process of the pipe reader in this case,
right? (If it's the other way around, the pipe writer should better terminate
when the pipe reader is gone, hence it should have SIGPIPE set to SIG_DFL.)
Then the detection whether the pipe reader has terminated unexpectedly should
better be done through the exit code, IMO, rather than by continually writing.

In this scenario, the pipe writer is expected to terminate before the pipe
reader.

The majority use-case of pipes is when you don't know ahead of time which
of the two processes, pipe reader of pipe writer, will terminate first.
In this case, EPIPE may occur as part of normal operation, depending on the
timing of the two processes. close_stdout is not currently usable in this
situation.

If you want both scenarios - the "don't know which of the two terminates first"
and the "writer must terminate first" - to be supported by close_stream and
close_stdout, IMO the program needs to be able to tell these functions about
it, probably through a global variable 'bool ignore_epipe' or similar.

Bruno





reply via email to

[Prev in Thread] Current Thread [Next in Thread]