Re: [RFC/PATCH] avoid SIGPIPE warnings for aliases

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

 



Jonathan Nieder <jrnieder@xxxxxxxxx> writes:

> I'm not sure whether there are SIGPIPE instances we really don't want
> to be silent about, though.  I suspect not. ;-)
>
> Compare <http://thread.gmane.org/gmane.comp.version-control.git/2062>,
> <http://thread.gmane.org/gmane.comp.version-control.git/48469/focus=48665>.

Yeah, thanks for the pointer to 48665.  Quoting from there:

    So EPIPE really _is_ special: because when you write to a pipe,
    there's no guarantee that you'll get it at all, so whenever you get
    an EPIPE you should ask yourself:

     - what would I have done if the data had fit in the 64kB kernel
       buffer?

     - should I really return a different error message or complain just 
       because I just happened to notice that the reader went away
       _this_ 
       time, even if I might not notice it next time?

    In other words, the "exit(0)" is actually _more_ consistent than
    "exit(1)", because exiting with an error message or with an error
    return is going to depend on luck and timing.

and I think I still agree with the analysis and conclusion:

    So what _should_ you do for EPIPE?

    Here's what EPIPE _really_ means:

     - you might as well consider the write a success, but the
       reader isn't actually interested, so rather than go on, you
       might as well stop early.

    Notice how I very carefull avoided the word "error" anywhere.
    Because it's really not an error. The reader already got
    everything it wanted. So EPIPE should generally be seen as an
    "early success" rather than as a "failure".

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]