Re^2: cleanly exiting threads

Thanks for this, it has greatly helped with some cases where the tests I'm running actually hang or fail (due to bad hardware or inserted faults).

Here's what I ended up actually implementing

use threads;    
use Thread::Queue;
use threads::shared;
use IPC::Open2;

sub pipeCommand ($$$$;@) {
    my $uut   = shift;
    my $cmd   = shift;
    my $test  = shift;
    my $wd    = $homedir;
    $wd      .= shift;
    my @input = @_ ? @_ : ();

    my $thread = async {
        my $tid = threads->tid();
        my ( $out, $in );
        $cmd = "cd ".$wd."; ".$cmd;
        my $pid = open2( $out, $in, $cmd );
        print $in "$_\n" foreach (@input);
        close $in or warn "close of input: $! $?\n";
        my $err = 0;
        while (<$out>) {
            last if ($die);  #drops me out of loop and lets me exit cl
+eanly
            chomp;
            $err = 1 if (/^thread failed/);
            next unless length $_;
            $Q->enqueue("$tid:$uut:$test:$_");
            last if ($err);
        }
        kill( 2, $pid ) if ($err or $die);
        close $out or warn "close of output: $! $?\n";
        my $kpid = waitpid ($pid, 0);
        $Q->enqueue("$tid:$uut:$test:ENDEND");
        return;
    };
    $thread->detach();

    return ( $thread->tid() );
}
[download]

then I call set die in one of two ways: either via setting it at the end of the while(1) loop, or when an alarm is triggered

my $tests = 7; # a number of tests

sub recv_results {

    my $done      = 0;
    my $err_count = 0;

    while (1) {
        if ( $Q->pending ) {
            my $line = $Q->dequeue;
            $_ = $line;
            chomp;
            if (/ENDEND$/) {
                $done++;
            }
            last if ( $done == $t_count );
            last if (/^DIEDIE$/);
            next if (/ENDEND$/);
                        
            if (/some pattern/) {
                 #log something
            } 
            else {
                 #log something else
            }
        }
        else {
            usleep 5000;
        }
    }

    return $err_count;
}
[download]

sub ALRM_handler {
    alarm 0;
    $Q->enqueue("DIEDIE");
    $die = 1;
}
[download]

my $time = 3600; #or some number of seconds

launch_tests();

$SIG{ALRM} = 'ALRM_handler';

my $alrm = $time + 35; #little extra time for init and close

alarm $alrm;
my $err_count = recv_results();

$die = 1;    #this will force any threads that are still stuck in the 
+while loop to exit
[download]

At this point, I never have tests that mysteriously fail to start. (thanks for the pointer on the possible race condition), I always have every test that is started send its end to the results receiver (sometimes being voilently killed via the alarm and setting of die, which does go and kill the pid for the open process, close out, etc), and yet even still, I always have two threads upon exit; even when nothing goes wrong and everything completes normally.

I'm going to try a little bit with the join method instead of detach, but at this point i'm almost inclined to turn on ignore for them, as one of the monks had suggested. Since the OS seems to be cleaning them up for me okay...

however, any other thoughts would be welcome

Comment on Re^2: cleanly exiting threads Select or Download Code

Replies are listed 'Best First'.
Re^3: cleanly exiting threads by zentara (Cardinal) on Aug 15, 2008 at 13:17 UTC
Yeah it's gets tricky because each thread gets a copy of the parent at the time of creation, it's a Perl problem, not a c thread problem. That means a thread may have duplicated code from a previous thread in it, just sitting around keeping a refcount > 0. Hard to track down. The only absolutely foolproof way of doing it, is to create all threads at the beginning of the script, then REUSE the threads, over and over. See Reusable threads demo for the basic idea. Otherwise, you may be best just turning off the warning, and watch for weird glitches or memory gains as your script runs. All I can say is good luck, because I have run into similar problems many times, and now immediately use sleeping reusable threads right from the start of design. I don't even consider detaching, as it almost always leads to memory gains unless you somehow reuse the thread's scalar namespace. Also spawning threads is pretty intensive, so you want to minimize it......reuse threads and join at exit. I'm not really a human, but I play one on earth Remember How Lucky You Are	[reply]
Re^4: cleanly exiting threads by JoeKamel (Acolyte) on Aug 17, 2008 at 07:01 UTC
Okay, I've followed your primer, oh wise one. and guess what. No threads left. I'm not sure thank you really expresses my sentiments. Believe it or not, your "simple" example is actually rather complex compared to what I'm doing. In the spirit of an even simpler "example" (granted probably not that easy to read). Here is the (hopefully) final version of the code. I guess the 3rd re-write was the charm. I'm not sure if the below example will parse (probably not), but hopefully its enough to help the next poor fellow Read more... (6 kB) I really liked the way you setup your thread hash, and would have done that if I had found your original post 1st, but as it was, this seems to work (which is all that really matters) Thanks again. I really appreciate it.	[reply] [d/l]
Re^5: cleanly exiting threads by zentara (Cardinal) on Aug 17, 2008 at 12:05 UTC
I'm glad you got it going. Threads are such a buzzword now, and everyone wants to use them thinking they simplify design. Now that you see how to make them work, you can help straighten everyone out. :-) I'm not really a human, but I play one on earth Remember How Lucky You Are	[reply]