Beefy Boxes and Bandwidth Generously Provided by pair Networks
P is for Practical

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

by zentara (Archbishop)
on Feb 06, 2006 at 20:14 UTC ( #528320=note: print w/replies, xml ) Need Help??

in reply to Re^2: SIG{'PIPE'} and pipe timeout
in thread SIG{'PIPE'} and pipe timeout

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?

I'm not really a human, but I play one on earth. flash japh

Replies are listed 'Best First'.
Re^4: SIG{'PIPE'} and pipe timeout
by Marcello (Hermit) on Feb 06, 2006 at 21:15 UTC
    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)
      Hi, I went to 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.

      I'm not really a human, but I play one on earth. flash japh

        I will search there too. So probably it is rather harmless and can be IGNORE'ed.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://528320]
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others meditating upon the Monastery: (3)
As of 2020-07-05 09:46 GMT
Find Nodes?
    Voting Booth?

    No recent polls found