Re^13: "Thread already joined at..." and "A thread exited while x threads were running" errors

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

Comment on Re^13: "Thread already joined at..." and "A thread exited while x threads were running" errors Download Code

Replies are listed 'Best First'.
Re^14: "Thread already joined at..." and "A thread exited while x threads were running" errors by nickos (Initiate) on Sep 07, 2004 at 16:20 UTC
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]
Re^15: "Thread already joined at..." and "A thread exited while x threads were running" errors by BrowserUk (Patriarch) on Sep 07, 2004 at 19:19 UTC
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]
Re^16: "Thread already joined at..." and "A thread exited while x threads were running" errors by nickos (Initiate) on Sep 08, 2004 at 13:30 UTC
Yeah, thanks for that. I would really have preferred to get the output, but I spose I'll have to live without it. I entered the problem on ActiveStates bug reporting system so they're aware of the problem (after reading up on it a bit I don't think it's a job for the perlbug@perl.org guys). Oh yeah, I tested it on AIX as well and it worked fine. I think I heard somewhere that Microsoft improved the threading model in Windows XP, so maybe whoever ported Perl to Windows took advantage of the new functionality and forgot to test it on the older systems...	[reply]