Send behavior on Broken pipe
While writing a simple server-client application, this question came in my mind. When someone tries to write to a broken pipe, a SIGPIPE would be generated. Let's say I handle the signal in my code.
Now what error does the write call returns - EPIPE or EINTR ( as it was interrupted by a signal). I tried with a sample program and I seem to be getting EPIPE always. Is this a guaranteed behavior or it could be any of the two error values?
POSIX says that EPIPE should be returned and SIGPIPE sent:
- For write()s or pwrite()s to pipes or FIFOs not open for reading by any process, or with only one end open.
- For write()s to sockets that are no longer connected or shut down for writing.
You can have a look at the POSIX standard here
You'll get EPIPE if you handle, block, or ignore the signal. Otherwise the process is terminated by default, see signal(7).
In general, "interrupted by a signal" (EINTR) refers to the utterly ridiculous Unix System V signal handling, whereby ANY system call could fail if your process received (and handled) a signal during the system call. This required wrapping every system call with do ... while (ret==-1 && errno==EINTR); or similar. While POSIX still allows either this or the good ("BSD") behavior, sane systems like GNU/Linux have the BSD behavior by default. You can always obtain the BSD behavior by calling sigaction with the right arguments, or even make a wrapper function to do so for you.
As such, EINTR is unrelated to the SIGPIPE caused by write errors.