This is nothing to do with signals or signal handling; and it is a bug.

It appears to stem from the piped-open filehandle being cloned into the thread causing a conflict when the thread is joined.

A simple workaround is to start the thread before you do the piped open:

#! /usr/bin/perl -w

use strict;
use threads;

my $break = 0;
$SIG{INT} = sub { $break=1; };

sub calculation {
    local $SIG{INT} = 'IGNORE';
    print("calculating something\n");
    5;
}
my $thread = async(\&calculation);

# Starting a co-process to read from.
my $procid = open(
    READ, '-|',
    'perl -e "$|=1; $SIG{INT} = \'IGNORE\'; for ($i=0;$i<10;$i++) {pri
+nt \"Line $i\n\"; sleep 1;}"'
);

# Reading from co-process.
until ($break) {
    my $line = <READ>;
    last unless defined $line;
    print $line;
}

if ($break) { kill('ABRT', $procid); }
close(READ);

print $thread->join() ."\n";
[download]

You should raise a perlbug against this. The following minimised code demonstrates the problem (5.10.1):

#! /usr/bin/perl -w
use strict;
use threads;

sub calculation {
    print("calculating something\n");
    5;
}

# Starting a co-process to read from.
my $procid = open(
    READ, '-|',
    'perl -e "$|=1; for (1..10) {print \"Line $_\n\"; sleep 1;}"'
);

##switch the order of the previous and next lines and the crash does n
+ot occur.
my $thread = async(\&calculation);

# Reading from co-process.
until ( 0 ) {
    my $line = <READ>;
    last unless defined $line;
    print $line;
}

close(READ);

print $thread->join() ."\n";
[download]