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?

Answers


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.


Need Your Help

Customizing Visual Studio

c# asp.net winforms visual-studio

I have been working with Visual Studio (WinForm and ASP.NET applications using mostly C#) for several months now. For the most part my IDE is set up fairly standard but I have been wondering what ...

windows authentication with Entity Framework and IIS

c# asp.net authentication iis-7 entity-framework-4

Publishing the default visual studio ASP site on IIS everything is ok.