You can either ignore SIGPIPE signals and wait for syswrite to return 0, or you can listen for SIGPIPE signals

I think you meant "return undef" here...

Call me a Un*x biggot but I have been thinking about this some more. I just could not quite remember something about SIGPIPE and sockets in the context of a select loop.

First let us look at the easy case i.e pipes or fifos. By default they are "blocking".

A SIGPIPE is an exceptional condition (like the receiving of any other signal except SIGCHILD maybe as it is a system "rule"): a write to a pipe or fifo without reader will generate a SIGPIPE for that writer.

EOF on a fifo or pipe is a normal condition, generated when the last writer on a FIFO closes it (in the case of a pipe when the writer closes it) and the reader tries to read.

In the context of a select loop EOF at the read end of a connection is also a normal condition. Two system calls actually cooperate: select indicates a desc.(fh) is ready for reading if the next read gives EOF; in that case Perl's sysread will return num. 0.

Select will indicate that a desc.(fh) is ready for writing when the other end has closed its side of the connection. The next call to syswrite will return undef (and sets $! to EPIPE) and in complete analogy with the pipe/fifo case a SIGPIPE will be generated.

Still there is an important difference, in a select loop you usually manage quite a few "write" desc. and an isolated signal does not really pinpoint the "guilty" desc.; so usually you would mostly ignore SIGPIPE in the context of a select loop (not so for a "pipeline"). This is what I could not remember at first.

hth --stephan