in reply to Re^3: Why do my threads sometimes die silenty?
in thread Why do my threads sometimes die silenty?

If you added a sleep to the main thread (at the same position as the commented out join, then you would see the error because the slave thread would get a timeslice will the main thread was sleeping.
Interesting... indeed, if I put a sleep at the end of the script, I do indeed see the error.
But why would you comment out the join?
I did this to simulate a situation where the main thread gets stuck waiting for some message from the slave thread, which never actually comes because the thread died before sending it. In that situation, the master thread never gets a chance to execute a join(), and so, I don't get to see the error message, even if I do Crtl-C. Or so I thought... Your comment leads me to think that this is not the case. Indeed, here's a piece of code that proves that: 
use strict;

use threads;
use threads::shared;
my $signal = undef;
share($signal);
my $fct = 
        sub {
            require Blah; Blah->import(); 
            $signal = 1;

        };
my $thr = threads->new($fct);
while (!$signal) {
    print "Sleeping and waiting for signal from slave thread\n";
    sleep(1);
}
print "Got message from slave thread\n";
$thr->join();

[download]
When I execute this, I get: 
Sleeping and waiting for signal from slave thread
Thread 1 terminated abnormally: Can't locate Blah.pm in @INC (@INC con
+tains: etc...
Sleeping and waiting for signal from slave thread
Sleeping and waiting for signal from slave thread
etc...

[download]
In other words, the master does get stuck waiting for a message that will never come, but the error is still printed.

Like I said earlier, I am having difficulty reproducing the exact circumstances "in vitro". I'll keep working at it and post new developments here. One difference between my app and the above simple example is that I am actually using a Thread::Pool to run the slave.

Replies are listed 'Best First'.
Re^5: Why do my threads sometimes die silenty?
by BrowserUk (Patriarch) on Sep 21, 2011 at 21:09 UTC
    One difference between my app and the above simple example is that I am actually using a Thread::Pool to run the slave.

    I cannot council you enough to drop Thread::Pool like a hot brick. My previous experiences with that module -- both my own experiments with it and those of questions posted here -- are all bad.

    It is (IMO) grossly over-engineered and fatally flawed in both concept and execution. Bloat-ware of the very worst kind and entirely unnecessary. Constructing a pool of threads is so extremely simple that there is no reason whatsoever to use that module or any like it.

    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.
[reply]
      "I cannot council you enough to drop Thread::Pool like a hot brick. My previous experiences with that module -- both my own experiments with it and those of questions posted here -- are all bad."
      Yeah, it's a bit overengineered allright, but I figured, why reinvent the wheel? Actually, I had started writing my own threadpool and ran into all sorts of problems, then found out about Thread::Pool. Maybe I should go back to implementing my own.
[reply]
        Maybe I should go back to implementing my own.

        There is no need, nor any point to implementing it as a module.

        It takes exactly 5 lines of code: 

        #! perl -slw
use strict;
use threads;
use Thread::Queue;

sub worker {
    my $Q = shift;
    my $tid = threads->tid;
    print "Thread $tid started";
    while( defined( my $work = $Q->dequeue ) ) {
        print "Thread $tid processing workitem $work";
        sleep 1;
    }
    print "Thread $tid done";
}

our $WORKERS //= 10;
our $ITEMS   //= 30;

my $Q = new Thread::Queue;                                    ## 1
my @pool = map threads->new( \&worker, $Q ), 1 .. $WORKERS; ## 2
$Q->enqueue( 1 .. $ITEMS );                                  ## 3
$Q->enqueue( (undef) x $WORKERS );                           ## 4
$_->join for @pool;                                           ## 5

__END__
C:\test>tqpool -WORKERS=3 -ITEMS=10
Thread 1 started
Thread 2 started
Thread 2 processing workitem 1
Thread 3 started
Thread 3 processing workitem 3
Thread 1 processing workitem 2
Thread 2 processing workitem 4
Thread 3 processing workitem 5
Thread 1 processing workitem 6
Thread 2 processing workitem 7
Thread 3 processing workitem 8
Thread 1 processing workitem 9
Thread 2 processing workitem 10
Thread 3 done
Thread 1 done
Thread 2 done

        [download]
        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.
[reply]
[d/l]
Re^5: Why do my threads sometimes die silenty?
by alain_desilets (Beadle) on Sep 21, 2011 at 21:22 UTC
    Here is an example that more closely approximate my app's situation: 
    use strict;

use threads;
use threads::shared;
use Thread::Pool;

my $signal = undef;
share($signal);
my $fct = 
        sub {
            require Blah; Blah->import(); 
            $signal = 1;
        };
print "Starting the Thread::Pool\n";
my $pool = Thread::Pool->new(
                {do => $fct});
print "Thread::Pool started\n";

print "Sending a job to the Thread::Pool\n";
$pool->job();
print "Job sent to the Thread::Pool\n";

print "Waiting for the slave thread to set the shared signal\n";
while (!$signal) {
    print "Sleeping and waiting for signal from slave thread\n";
    sleep(1);
}
print "Got shared signal from slave thread\n";

$pool->shutdown();

    [download]
    When I run it, I get: 
    Starting the Thread::Pool

    [download]
    And it gets stuck there, without outputting any error message. Obviously here, the slave gets a slice of CPU, since I sleep for 1 second between polls of the shared signal.

    Note that if I coment out the faulty require line, I do get the proper behaviour, i.e. the script prints: 
    Starting the Thread::Pool
Thread::Pool started
Sending a job to the Thread::Pool
Job sent to the Thread::Pool
Waiting for the slave thread to set the shared signal
Sleeping and waiting for signal from slave thread
Got shared signal from slave thread

    [download]
[reply]
[d/l]
[select]

      What happens (*) if you change this:

      my $signal = undef;
share($signal);

      [download]

      To: my $signal :shared; ?

      I can't test it as I don't have Thread::Pool. It isn't available as a PPM for my version of Perl and I cannot be bothered to try and track down the numerous crappy, bloated dependencies it has to install it manually, given that I would never use it.

      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.
[reply]
[d/l]
[select]
        Changed the $signal declaration to my $signal :shared; as you suggested, and I get the same behaviour as before. The thread never returns (because of the faulty "use Blah"), but I never see the error message. Alain
[reply]
[d/l]

In Section Seekers of Perl Wisdom