views:

62

answers:

1

I'm using Thread::Pool::Simple for multi-threading. I have a couple of questions which are quite general to multi-threading, I guess:

Each of my threads might die if something unexpected hapens. This is totally accepted by me, since it means some of my assertion are wrong and I need to redesign the code. Currently, when any thread dies the main program (calling thread) also dies, yielding something like:

Perl exited with active threads:
    0 running and unjoined
    0 finished and unjoined
    4 running and detached
  1. Are these "running and detached" zombies? Are they "dangerous" in any way? Is there a way to kill all of them if any of the threads dies? What is the common solution for such scenarios?
  2. Generally, my jobs are independent. However, I pass each of them as an argument a unique hash which is taken form one big hash oh hashes. the thread might change this personal hash (but it can't get to the large hash - it doesn't even know about it). Hence, I guess I don't need any locks etc. Am I missing anything?
+1  A: 

When your main program exits, all threads are terminated.

Perl threads work in one of two ways.

1) You can use join:

my $thr = threads->create(...);
# do something else while thread works
my $return = $thr->join(); # wait for thread to terminate and fetch return value

2) You can use detach:

my $thr = threads->create(...);
$thr->detatch(); # thread will discard return value and auto-cleanup when done

That message lists the threads that hadn't been cleaned up before the program terminated. "Running and unjoined" is case 1, still running. "Finished and unjoined" is case 1, finished but the return value hasn't been fetched yet. "Running and detached" is case 2, still running.

So it's saying you have 4 threads that had been detached but hadn't finished before the program died. You can't tell from that whether they would have finished if the program had run longer, or they were stuck in an infinite loop, or deadlocked, or what.

You shouldn't need any locks for the situation you describe.

cjm
re locks - and what if I pass the large hash along with a key, and the thread only uses the inner hash pointed by that key?
David B