15

I'm wondering what was the thinking behind having a SIGPIPE signal.

From my own experience, the first thing I do is turn off that signal (SIGIGN) and use the return value of the calls to make sure it isn't now closed (i.e. errno == EPIPE).

The only one thing I could come up with is: programmers at the time wanted to pipe between processes in a shell so they would do work until the first SIGPIPE and just exit. However, even that, if you pipe-in and pipe-out, then you'd need to know whether the SIGPIPE was for the input and if so continue the work until your data was all processed... I guess you can first assume that the SIGPIPE was from the input and not fail. If you receive SIGPIPE again, just fail.

So even early on, the signal would be difficult to work with, wouldn't it?

P.S. I'm not interested about sockets that came later.

Improve this question
2
  • 16
    You don't "need to know whether the SIGPIPE was for the input" because it was only generated when writing to a broken pipe. It was a nice simple way to write a filter without doing any error checking. If for any reason the filter can't write to a pipe, SIGPIPE kills it. That's better than the filter eating up resources processing more input when there is nowhere for the output to go.
    – alephzero
    Jul 18, 2021 at 19:38
  • 4
    @alephzero mind to turn that into an answer?
    – Raffzahn
    Jul 18, 2021 at 19:40

1 Answer 1

Reset to default
34

You get SIGPIPE only if you try to write to a pipe that has no readers anymore. The idea is that typical unix processes run to produce output. If the output is going to a pipe, but no one is reading from a pipe, the process got useless and may be killed.

You never get SIGPIPE reading from an input pipe. If you read from an input pipe that has no writers anymore, you just get EOF. The usual behaviour of a process that reads EOF is finishing input processing. So you get the behaviour you suggest for nice filters "for free" without adding extra logic like counting SIGPIPEs.

The idea of the default behaviour is meant to make the standard UNIX idiom of reading standard input, transforming it in some way, and writing the result to standard output work by default. If your process writes to files in a more complex patterns, it often is a good idea to change the default "process is killed by SIGPIPE" behaviour. But in this case your process is already complex enough that the extra complexity of changing SIGPIPE handling doesn't significantly affect binary size or runtime.

Improve this answer
9
  • 2
    @another-dave Indeed. And thus it seems like it would have made sense to have every output write error kill the process. Writing to a dead pipe makes just as little sense as writing to a full disk. Yet there is no SIGSPC that you receive by default instead of an -ENOSPC return value.
    – Michael Karcher
    Jul 18, 2021 at 21:12
  • 8
    @MichaelKarcher Not really. If my text editor can't save my file, I don't want it to throw away the only extant copy.
    – wizzwizz4 ♦
    Jul 18, 2021 at 21:29
  • 4
    @wizzwizz4 A text editor is part of the "very complex software" which will catch the SIGSPC...
    – Alexis Wilke
    Jul 18, 2021 at 21:30
  • 5
    @AlexisWilke Imagine it's buggy, or the programmer forgot. “Claims to have saved the file but didn't” is much better than “pressing save is a risky action” as a default behaviour.
    – wizzwizz4 ♦
    Jul 18, 2021 at 22:04
  • 2
    @wizzwizz4: Any text editor that has "doesn't handle saving very well" as a bug is to be avoided... that is true regardless of any advantages or otherwise of a (hypothetical) SIGNOSPC signal :)
    – psmears
    Jul 19, 2021 at 13:31

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .