Bruno Haible <[EMAIL PROTECTED]> 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.
