Re^2: SIG{'PIPE'} and pipe timeout

[Marcello]

Thank you for your reply.

socketpair is mentioned in Perl IPC as one of the methods to create two pipes. There are no other pipes created, and it happens as soon as the process is writing to the pipe.

Regards, Marcel

[zentara]

I don't want to start arguing over this, but I read that section in perlipc, and it dosn't say that pipes are created with socketpair. It says that socketpair is preferred for bidirectional communication , over 2 pipe pairs. The name, "pipe2" may be misleading.

....snip......
 # pipe1 - bidirectional communication using two pipe pairs
           #         designed for the socketpair-challenged

...snip.......

 But you don't actually have to make two pipe calls.  If you have the 
+socketpair() system call, it will do this all for you.
 #!/usr/bin/perl -w
 # pipe2 - bidirectional communication using socketpair
 #   "the best ones always go both ways"

So you are not creating a pipe with socketpair, that is why I brought it up in my original post, about you relating a SIG{PIPE} to the socketpair. I was thinking that somewhere in your program, you had a pipe ( liked a piped open ) which prints to the socket.

It really would be good if you could show a snippet of code which gives your error. Does the code in perlipc (pipe2), showing how to use a socketpair, work OK for you? It works OK for me. How does your code differ from it?

[Marcello]

Here is my code:

    my $child = my $parent = my $pid = undef;

    # Create a socket pair from IPC (both ways)
    if (!socketpair($child, $parent, AF_UNIX, SOCK_STREAM, PF_UNSPEC))
+ {
        die "socketpair failed: ".$!;
    }
    else {
        # Flush messages immediately
        $child->autoflush(1);
        $parent->autoflush(1);

        if (!defined($pid = fork())) {
            die "Fork failed: ".$!;
        }
        elsif ($pid == 0) {
            close($child);

            # Here the process will carry out the work, and also write
+ to the 'pipe'
            # It will only exit this loop upon SIGTERM

            # Close the pipe with the parent
            close($parent);
            exit 0;
        }
        else {
            close($parent);
        }
    }

The pipe signal only occurs after a long period of inactivity on the client side, not on the server side (which also uses the 'pipe' to send messages to the client)

[zentara]

Hi, I went to http://groups.google.com and searched for "SIG PIPE socket" and got a bunch of hits about odd SIG{PIPES} on sockets.

One of the better responses said that you should just set $SIG{PIPE} = 'IGNORE'; as a good precaution. The causes can vary, but one reply said

The kernel will post a SIGPIPE to a process when it writes to a pipe, fifo, or network endpoint that is no longer open for reading. The primary reason for this behavior is to expeditiously terminate processes that write to their stdout stream but do not check the exit status of the write() call. For programs that are well behaved (i.e., those which check the status of calls to write(2)) it is best to simply set SIGPIPE to be ignored.

So maybe your client closes up(goes to sleep?) after a long period of inactivity, maybe you should strobe it every hour with a newline or something.