in reply to Re^11: "Thread already joined at..." and "A thread exited while x threads were running" errors
in thread "Thread already joined at..." and "A thread exited while x threads were running" errors

Okay, can this testcase be made any smaller (apart from by removing the print statements)? 
#! perl -slw
use threads;

use strict;
use warnings;

#my $command = q[printA.exe];
my $command = q[perl -wle"sleep int rand 3; print 'step1'"];

my $numCompleteTestRuns = 100;

runTests();

sub runTests
{
    my @threadList = ();

    for my $i (0 .. $numCompleteTestRuns)
    {
        print("About to create thread $i:");
        my $thread = threads->new(\&stepThread);
        push (@threadList, $thread);
    }

    my $numThreads = @threadList;
    print("There are $numThreads threads");

    # wait for each running thread to end
    foreach my $thread (@threadList)
    {
        $thread->join;
        print("A thread joined");
    }
    print("Processes ended - Goodbye");
}

# thread runs a type of users steps once only
sub stepThread
{
    print("Starting thread and about to run: $command");
    my $output = `$command`;
    print("$output");
    print("Ending thread");
}

[download]
  • Comment on Re^12: "Thread already joined at..." and "A thread exited while x threads were running" errors
  • Download Code

Replies are listed 'Best First'.
Re^13: "Thread already joined at..." and "A thread exited while x threads were running" errors
by BrowserUk (Patriarch) on Sep 07, 2004 at 16:00 UTC

    That looks fine. I just ran it a dozen or so times on my setup and it completes perfectly every time.

    Perhaps the only other thing I would try is to reduce the command that you run to a simple `dir > nul`; and see what, if any, difference that makes.

    Examine what is said, not who speaks.
    "Efficiency is intelligent laziness." -David Dunham
    "Think for yourself!" - Abigail
    "Memory, processor, disk in that order on the hardware side. Algorithm, algorithm, algorithm on the code side." - tachyon
[reply]
[d/l]

      Okay, I'm now using:

      my $command = q[dir > nul];

      and it still doesn't work. I guess I'll email perlbug@perl.org tomorrow like you suggested...

      I'm supposed to get this working by Friday. Can you think of any workarounds?

[reply]
[d/l]

        I've managed to re-create the problem here. By using my $output = `dir \largedir\*`, to force perl to capture a large volume of data from the backticks, I can get program to hang. If I redirect the output to a file or nul, it doesn't happen. If the volume of output from the command is small, it doesn't happen.

        So it appears to be related to the capture of output by the backticks. Somewhere, a deadlock is occuring.

        So, how important to your application is it to capture the output? I substituted system 'dir \largedir\*'; and it ran perfectly again. Maybe if you can live without capturing the output, you could do the same until someone manages to track down the cause of the backticks problem?

        I don't think that I will be able to take this much further as everytime I try to build a debug version of perl it goes belly up. I'll set it running under an external debugger and see if I can interupt it when the deadlock occurs, but I don't hold out much hope. Even if I succeeded, it would only be a little extra info for the p5p guys to work with--it would still be upto them to work out what is causing the deadlock and how to fix it.

        Remember that they are volunteers. Don't expect anything by Friday. Indeed, it would probably be wise not to mention that.

        Examine what is said, not who speaks.
        "Efficiency is intelligent laziness." -David Dunham
        "Think for yourself!" - Abigail
        "Memory, processor, disk in that order on the hardware side. Algorithm, algorithm, algorithm on the code side." - tachyon
[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom