SIGPIPE propagation

[Robert Watson]

On Sat, 1 Mar 2008, Martin Laabs wrote:

> as you probably know I want to expand dump in such a way it enableds 
> multivolume dumps also when the output data is written to stdout/a pipe. Now 
> I ran into a serious problem. Dump counts the written bytes to remember 
> where it has to proceede after the volumen change. Now the SIGPIPE signal 
> does not propagate fast enought through the system. Thus dump writes some 
> time after the pipe has got broken data into the pipe while it doesn't exist 
> anymore. This short time it does not receive any error about that. (Until 
> the signal propagates to dump.) I wrote a small test progam to demonstrate 
> this effect (and get clear about it by myself). It just write data to stdout 
> and counts it until the pipe is broken (and the write call will return -1) 
> This is the output of a few successively runs:

Here's how SIGPIPE works: when one endpoint of a pipe or socketpair is closed, 
the other endpoint will be flagged to return EPIPE for any further system 
calls to write to the pipe or socket.  The interesting case involves what to 
do if there is already an in-progress system call for a thread writing to it. 
There are a few cases from the perspective of an application writer:

(1) The write is issued "before" the close and can be fully satisfied without
     sleeping, in which case it returns the number of bytes written.

(2) The write is issued "after" the close and returns EPIPE and/or SIGPIPE
     depending on signal disposition, socket options, etc.

(3) The write is issued "during" the close, and in particular, in a case where
     the write was blocking waiting on the reader to make more space available
     to hold all of the written data.  The kernel will return a positive
     integer that is potentially smaller than the requested write because it
     has written some bytes successfully, and the next write will return EPIPE.

I think you may be tripping over case (3) if you are using blocking I/O on the 
pipe/socketpair -- some data was written, just not all of it, and the remote 
close interrupted the write, leading to a success response followed by an 
asynchronous failure on the next write.  SIGPIPE, FYI, is generated in the 
writer context due to EPIPE coming back from the socket/pipe code, and not 
generated by the closing of the remote socket endpoint, so SIGPIPE will not be 
delivered until a write is attempted on a socket with no remote endpoint.

Does this explain the behavior you were seeing?

Robert N M Watson
Computer Laboratory
University of Cambridge

>
>
> $ ./a.out |asdf
> $ asdf: command not found
> cought broken pipe
> i: 12 could only wrote -1 bytes. total wrote: 61440
>
> $ ./a.out |asdf
> $ asdf: command not found
> cought broken pipe
> i: 1 could only wrote -1 bytes. total wrote: 5120
>
> $ ./a.out |asdf
> $ asdf: command not found
> cought broken pipe
> i: 12 could only wrote -1 bytes. total wrote: 61440
>
> $ ./a.out |asdf
> $ asdf: command not found
> cought broken pipe
> i: 0 could only wrote -1 bytes. total wrote: 0
>
>
> Dump encounters the same effect and I don't know how
> to handle this problem. Do you have any idea how I
> can manage this?
>
> Thank you,
> Martin L.
>
> PS: Here's the code of the small test-program:
>
> -----------------:<----------------
> #include <stdio.h>
> #include <sys/types.h>
> #include <sys/uio.h>
> #include <unistd.h>
> #include <errno.h>
> #include <sys/errno.h>
> #include <fcntl.h>
> #include <signal.h>
>
> #define MUL 5
> char            buffer    [1024 * MUL];
>
> void
> sigpipe(int signo __unused)
> {
>       fprintf(stderr, "cought broken pipe\n");
> }
>
> main()
> {
>       int             i         , w;
>       int             wr = 0;
>
>       signal(SIGPIPE, sigpipe);
>
>       for (i = 0; i <= 100; i++) {
>               w = write(STDOUT_FILENO, buffer, MUL * 1024);
>               if (w > 0)
>                       wr += w;
>               if (w != 1024 * MUL) {
>                       fprintf(stderr, "i: %d could only wrote %d bytes. 
> total
>                       break;
>               }
>       }
> }
> ------------------------:<--------------------------------
> _______________________________________________
> freebsd-hackers at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe at freebsd.org"