Beefy Boxes and Bandwidth Generously Provided by pair Networks
"be consistent"
 
PerlMonks  

Why do my threads sometimes die silenty?

by alain_desilets (Beadle)
on Sep 21, 2011 at 19:15 UTC ( #927205=perlquestion: print w/ replies, xml ) Need Help??
alain_desilets has asked for the wisdom of the Perl Monks concerning the following question:

I'm experimenting with multi-threading in Perl, and I find that often, one of the slave threads dies, but I don't get to see the error message at all.

I haven't been able to identify specifically the circumstances under which the thread dies silently or not, but when it does, it's very hard to zero in on the source of the error.

Is there a way to avoid this problem?

Thx.

Comment on Why do my threads sometimes die silenty?
Re: Why do my threads sometimes die silenty?
by BrowserUk (Pope) on Sep 21, 2011 at 19:29 UTC

    Without some clues as to what is going on, it is impossible to diagnose the cause. And therefore difficult to suggest a solution. But I do understand your difficulty in providing those clues.

    The single simplest help you could give us, is to post the code of a thread procedure that you know has silently died. If you have more than one, post them all.

    One trick I've previously used to track down a similar problem is to wrap the thread procedure in a block eval. So for example, if you have code like this:

    sub worker { .... } ... my @workers = map threads->new( \&worker, ... ), 1 .. $WORKERS;

    Make the following simple modification:

    sub worker { .... } sub proxy { my( $code, @args ) = @_; eval{ $code->( @args ) } or print $@; } ... my @workers = map threads->new( \&proxy, \&worker, ... ), 1 .. $WORKER +S;

    This may yield some clues. But posting the code of known to (sometimes) silently die thread subs would likely get better answers.


    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 think what's happening is this:

      • The master thread starts the slave thread
      • The master thread then waits for messages from the slave to appear in a shared message queue
      • The slave thread dies before it gets to send even a first message
      • As a result, the master thread never joins the slave thread, and this causes the error message to not be printed
      Below is a piece of code that illustrates this:
      use strict; use threads; use threads::shared; my $fct = sub { # eval {require Blah; Blah->import()} or print $@; require Blah; Blah->import(); }; my $thr = threads->new($fct); #$thr->join();
      When executed as is, it produces the following output:
      Perl exited with active threads: 1 running and unjoined 0 finished and unjoined 0 running and detached
      If I remove the comment in front of the last line (the join call), then I get error message:
      Thread 1 terminated abnormally: Can't locate Blah.pm in @INC (@INC con +tains: etc...
      Note also that the eval {} trick doesn't seem to make any difference. In other words, if I remove the comment in from of the eval {} line but leave the join() statement commented out, I still don't get the error message.

      Note also that the silent dying does not happen if, for example, the error is caused by a division by zero instead of a non-existant include file.

      Also interesting is the fact that if I do "use Blah;" instead of "require Blah; Blah->import()", then I see the error message, even if the join call is commented out.

      In case you are wondering why I use a require instead of use, it's because loading the Blah module may end up loading modules which are not thread-safe. Therefore, I want to load the module at run-time, not at compile time (as explained on this node: http://www.perlmonks.org/?node_id=288022).

        With the join commented out, the main thread (and therefore the entire process) terminates before the slave thread ever gets a timeslice. Therefore Perl never attempts to execute the require and so no error message is produced.

        The point here is that the code in the new thread does not get run immediately when you execute the threads->create(). It will not be run until some time later when the OS gets around to allocating it a timeslice. On a single core system this wouldn't happen until the main thread completes its timeslice. On a multi-core system it may get run concurrently with the main thread depending upon the current state of the OS load (including all other processes and system threads). But there is no way to predict how much later that will be.

        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 while the main thread was sleeping.

        But why would you comment out the join?


        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.
Re: Why do my threads sometimes die silenty?
by ikegami (Pope) on Sep 21, 2011 at 19:59 UTC

    Seems to me a thread can exit in one of three ways.

    • By throwing an exception.

      $ perl -Mthreads -e'my $t = async { die "Foo" }; $t->join; say "done"' Thread 1 terminated abnormally: Foo at -e line 1. done

      This isn't silent.

    • By returning.

      $ perl -Mthreads -E'my $t = async { "code" }; $t->join; say "done"' done

      You can detect this as follows:

      $ perl -Mthreads -E'sub t { "code" } my $t = async { t(); warn("return +ed"); }; $t->join; say "done"' returned at -e line 1. done
    • By calling threads->exit

      $ perl -Mthreads -E'sub t { "code" } my $t = async { threads->exit(); +}; $t->join; say "done"' done

      You can detect this as follows:

      $ perl -Mthreads -E'my $o = \&threads::exit; *threads::exit = sub { wa +rn "exit"; $o->(@_) }; my $t = async { threads->exit(); }; $t->join; +say "done"' exit at -e line 1. done

    Another possibility is that your thread isn't responding because it's blocked, not because it exited. What makes you think it died?

      There is at least one more way:

      C:\test>perl -Mthreads -E"my $t = async { die "Foo" }->detach; say 'do +ne'" done

      And I'm pretty sure I could come up with a few more.


      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 pretty sure the OP meant the thread exited before the process terminated.

        Note that the above is not silent if the die has a chance to execute. (About 50% of the time on this machine.)

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://927205]
Approved by lidden
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others meditating upon the Monastery: (8)
As of 2014-12-21 12:06 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    Is guessing a good strategy for surviving in the IT business?





    Results (104 votes), past polls