Try it this way. Put your cleanup code in an END{} block and just exit on the signal. (You'll need to cause your threads to terminate; hence $sig :shared; ):

#! perl -slw
use strict;
use threads;
use threads::shared;

my $sig :shared = 1;

$SIG{'INT'} = sub{ print 'sigint'; $sig = 0; exit; };

my @threads = map{
    async{ sleep 1 while $sig };
} 1 .. 4;

sleep 1 while 1;

END{
    print 'joining...';
    $_->join for @threads;
    print 'joined.';
}

__END__
C:\test>junk39
sigint
joining...
joined.
[download]

What are the threads doing?

I'd ignore all signals instead of trying to join inside a sighandler

Signals and threading do not mix;

Hi.. thanks for your reply. I just found the problem is causing due to one thread. I have no problem if I turn that off. The function proc1 is using Thread::Queue. I tested without proc1 and it doesnt create any problem. Code of proc1 is like the below:

sub proc1 {
    $q = Thread::Queue->new();
    while($p = $q->dequeue()){
        if($p eq 'exit'){
            last;
        }
        .....
    }
    $q->end();
    threads->exit();
}
[download]

This: $q->dequeue() blocks internally on a cond_wait(), if no data is available in the queue. Signals will not interrupt threads::cond_wait().

That said, how will that queue ever receive anything?

It is created inside the thread and immediately goes into a dequeue(). As it was created inside the thread, no other thread has a handle to it, so no data can ever be queued to it.

Your design is broken.

---

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

I'm with torvalds on this Agile (and TDD) debunked I told'em LLVM was the way to go. But did they listen!

Also note one of BrowserUK’s comments, found in the “do not mix” thread cited above, that you can sometimes just detach the threads and let them go.   You do not need to join with them unless you need to know that they have all terminated.

As a categorical rule-of-thumb, do not attempt to do anything within a signal handler, because you have no way to know precisely what was going on at the time the signal was received.   (Although the Perl interpreter will safely maintain its own internal state.)   Your handler should only raise some kind of yellow-flag, and maybe nudge threads that might be dozing so that they will see that the flag has been raised and they can react to it.   Time-consuming loops should include tests of the flag and break out of the loop.   (Another way to do it is to throw an exception.)   Only the main thread should be relied-upon to receive and act on the signal.   The flag itself (as shown elsewhere) must be thread-safe.   The signal handler may be called any number of times.

The signal should immediately cause some kind of acknowledgement message to be printed (to STDERR) so that the user will know that the program heard the bell ring.   The user should then see additional messages that show that it is, in fact, winding-up its affairs and shutting down.