Problem with threads + join

sumanth has asked for the wisdom of the Perl Monks concerning the following question:

Hi Perl Monks, Im working with perl 5.8.8. and when I do this

 my $thr = threads->create(\&function);
 $thr->join;

sub function {
}
[download]

I get a error " Attempt to free unreferenced variable SV: " while 'joining' the thread I came to know that perl 5.10.0 solves this. But for some reasons I cant port it to newer version as all the softwares are built on 5.8.8. What I essentially need is the main thread has to wait for the child thread to finish. But I couldnt do with join as my interpreter encounters problem. So I tried to use the following code snippet which uses semaphores.

use threads;
use threads::shared;
use Thread::Semaphore;

my $init = 0;
my $sem:shared;
$sem = new Thread::Semaphore($init);

my $thr = threads->new(\& process );

$sem->down;

sub process {

    lock($sem);
    $sem->up ;
    return;
    
}
[download]

Here also once semaphore count is incremented by the thread the main thread immediately finishes its execution and I am getting "A thread finished while 2 threads were running" Thats because the exexution may shift to main thread before the return is called. Can someone help me out. I found out it is actually a bug with internal reference count. Refer this bug

Comment on Problem with threads + join Select or Download Code

Replies are listed 'Best First'.
Re: Problem with threads + join by moritz (Cardinal) on Jun 07, 2008 at 09:47 UTC
(for sumanth: you find nothing new here. For the rest: I want to summarize a discussion we had on the CB, hopefully other monks can profit from it). This is a XY Problem. The reason not to simply call `$thread->join` was that this command reveals error messages like `attempted to free unreferenced scalar..`. I tested the code that produced the errors, and confirmed them on perl 5.8.8. On 5.10.0 they were fixed. Now sumanth can't upgrade to 5.10.0, and tries to find a workaround. While a workaround is perfectly fine (IMHO) when a feature is missing, I think in this case here it is folly, because generally working around a buggy environment is unproductive, and usually doesn't work in the end the `->join` call probably only reveals the error, it's likely not the cause. That means that the workaround is in the wrong place (if there is a right place at all) There seems to be an error somewhere that in perl's reference counting. If there is, and it is triggered by a program, it can result in bugs that are very hard to reproduce and hard to find, and perhaps even data corruption or loss. So I think to preserve your sanity, dear sumanth, you should find a different solution. Perhaps without threads (maybe forks or non-blocking IO might help?), perhaps with a second perl installation, perhaps with a different programming language.	[reply] [d/l] [select]
Re: Problem with threads + join by BrowserUk (Patriarch) on Jun 07, 2008 at 19:17 UTC
It's not clear from your post whether you are getting an actual trap or segfault as a result of trying to join your threads, or are you simply trying to avoid the "Attempt to free unreferenced variable SV:" warning? Also, which version of the threads module are you using? 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. "Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."	[reply]
Re: Problem with threads + join by zentara (Cardinal) on Jun 07, 2008 at 16:05 UTC
Well, a thread can't be joined unless it returns or reaches the end of it's code block. In my various thread examples posted, I use a $die shared variable to signal the thread to return, then it can be joined. If you can't use that in your thread code block, you can put a while() loop at the end of your main code, which checks the threads->list, until all are joined. See Just can't get threads to work The latest threads version available on cpan, has the ability to summarily kill a thread, which you can use on pesky threads that are locked up. If that fails, use detached threads, which don't need to be joined, and will exit when the parent exits. I'm not really a human, but I play one on earth CandyGram for Mongo	[reply]