Re: Is this a bug of perl threads?

[almut]

I can reproduce the problem with your client/server combo.  Running the server part under strace indicated the process had been "killed by SIGPIPE":

...
[pid 27966] write(4, "58\n", 3)         = -1 EPIPE (Broken pipe)
[pid 27966] --- SIGPIPE (Broken pipe) @ 0 (0) ---
Process 27966 detached
[pid 27967] <... accept resumed> 0x4219cef0, [4096]) = ? ERESTARTSYS (
+To be restarted)
[pid 27967] +++ killed by SIGPIPE +++
Process 27967 detached
[pid 27968] <... accept resumed> 0x4299def0, [4096]) = ? ERESTARTSYS (
+To be restarted)
[pid 27968] +++ killed by SIGPIPE +++
Process 27968 detached
<... futex resumed> )                   = ? ERESTARTSYS (To be restart
+ed)
+++ killed by SIGPIPE +++

Adding $SIG{PIPE} = 'IGNORE' to the server code solved the issue for me.  You probably also want to check if the print $client "$second\n" failed, in which case you should close the connection properly (otherwise, the respective threads will remain busy for 60 seconds printing to nowhere...):

    ...
        for ($second=60; $second>0; --$second) {
                sleep 1;
                last unless print $client "$second\n";
        }
        close $client;
    ...

[Ray.Zachary]

WOOOOOW, That's awesome! You are right!

Thank you almut, and thanks everybody, that problem was solved with handling $SIG{PIPE}.

Seems I need going to read some papers about signals.

[ikegami]

That particular signal occurs when you attempt to write to a pipe or socket that's been disconnected. The default action is to kill the process. You can safely ignore the signal. In exchange, you should check if print succeeds, and exit the loop if not.

sub server {
    local $SIG{PIPE} = 'IGNORE';
    while (my $client = $server->accept()) {
        for my $sec (1..60) {
            sleep 1;
            print $client "$sec\n"
                or last;
        }
    }
}