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

---

The write(2) call returns -1 on error, so I guess you are asking about the value of errno(3).

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.