in reply to unexpected program abort on write on closed handle

A broken pipe does indeed send a fatal signal to your program. If you want the behaviour to be otherwise, there are a couple of decisions you first might have to make:

Firstly, whether to handle the signal as a warning or an error. For example, you could assign $SIG{ PIPE } to a handler that treats it as a warning, e.g.

$SIG{ PIPE } = sub { warn "Broken pipe trap, traceback follows:\n" . T
+race::trace(); }

[download]
The second decision of course being whether to use Devel::Trace as would be necessary for the above example, so that the signal handler reports where in the code it was invoked.

One world, one people

Replies are listed 'Best First'.
Re^2: unexpected program abort on write on closed handle
by Beechbone (Friar) on Jul 25, 2005 at 09:23 UTC
    I'd like the syswrite() to simply return undef, nothing more. My existing code then will throw away the socket and try to (re-)connect to any available server. 
        TRY: for (1 .. $maxretries) {
        eval {
            $sock ||= outconnect() || die $diag=$!;
            my $lw = syswrite($sock, $$data);
            die $! unless defined $lw and $lw == length($$data);
            $$data = '';
        }; if (my $e = $@) {
            $diag ||= $e;
            $sock = undef;
            next TRY;

    [download]
    PS: Setting it to 'IGNORE' works just fine: Exception: Broken pipe at /root/iotest.pl line 31.
    Search, Ask, Know
[reply]
[d/l]
[select]
      You are of course right, that it can be made to be ignored. I forgot that because I am used to project standards that require all fatal conditions to at the least be written to a log file for review by production support personnel, even though this often leads to huge logfiles that need to be regularly archived off!

      One world, one people

[reply]

In Section Seekers of Perl Wisdom