[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: tee logs no output if stdout is closed
From: |
Jim Meyering |
Subject: |
Re: tee logs no output if stdout is closed |
Date: |
Fri, 03 Oct 2008 13:57:08 +0200 |
Bruno Haible <address@hidden> wrote:
> 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.
In some contexts. Some environments (mis-configured login/csh) have
resulted in the default SIGPIPE handler being SIG_IGN.
> 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
What if the writer and reader processes have no such relationship?
> 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.
Using a global variable would not be appropriate for library code like
this. What if two applications using the same library want to use
different policies?
While I don't like the alternatives much,
they're better in the long run.
- Re: tee logs no output if stdout is closed, Jim Meyering, 2008/10/03
- Re: tee logs no output if stdout is closed, Bruno Haible, 2008/10/03
- Re: tee logs no output if stdout is closed,
Jim Meyering <=
- Re: tee logs no output if stdout is closed, Bruno Haible, 2008/10/03
- Re: tee logs no output if stdout is closed, Jim Meyering, 2008/10/04
- Re: tee logs no output if stdout is closed, Bruno Haible, 2008/10/04
- Re: tee logs no output if stdout is closed, Jim Meyering, 2008/10/05
- Re: tee logs no output if stdout is closed, Bruno Haible, 2008/10/05
- Re: tee logs no output if stdout is closed, Jim Meyering, 2008/10/07
- Re: tee logs no output if stdout is closed, Paolo Bonzini, 2008/10/03
- Re: tee logs no output if stdout is closed, Jim Meyering, 2008/10/03
- Re: tee logs no output if stdout is closed, Paolo Bonzini, 2008/10/03
- Re: tee logs no output if stdout is closed, Jim Meyering, 2008/10/03