in reply to Activestate 5.8.2 broke my threads :(

I suspect it has to do with the threads object's lexical scoping and perl's garbage collector. I modified your code to below and it works -
#!/usr/bin/perl
use 5.008;             # 5.8 required for "stable" threading
use strict;
use warnings;
use threads;
use threads::shared;
use IO::SOCKET;
use Data::Dumper;

my @threads;
for (my $i = 0; $i < 5; $i++) {
    my $thread = threads->create(\&start_thread, "localhost:80");
    $thread->detach;
    push @threads, $thread;
}
sleep(2);
print STDERR "done\n";
exit;

sub start_thread {
   my $tid = threads->self->tid;
   print STDERR "Start $tid\n";
   sleep(1); # do something in the thread
   print STDERR "Finish $tid\n";
}

[download]
What I think is happenning is that threads->create creates a temporary object (in threads module, create is new), and this object goes out of scope at the end of the for block and Perl happily 'freed' it with the garbage collector. You have to make sure that the created threads object does not go out of scope to have it working properly.

Replies are listed 'Best First'.
Re: Re: Activestate 5.8.2 broke my threads :(
by pg (Canon) on Dec 22, 2003 at 06:16 UTC

    Roger, your explanation might have hit the bug behind it. (I don't comment, as it is speculation any way. We all know that they fixed lots of thread-related memory leaks in 5.8.2, at least according to the document. It is not a surprise that they might had some of the bugs over killed, and now free the same piece allocated memory twice. Not neccessary to be garbage collector related ;-)

    However this is not a fix, but rather a workaround, as the OP's code should be just fine, without the array you added. A Perl bug is still a Perl bug, and there is no point for application programmer to suffer from it, and worry about workaround.

[reply]
Re: Re: Activestate 5.8.2 broke my threads :(
by Anonymous Monk on Dec 22, 2003 at 16:30 UTC
    Roger, Thanks for your effort, much appreciated, especially that as side effect fixed my problem :), which I now consider real Perl 5.8.2 bug, at least for AS Windows. But one word first. My problem was also to do with sockets in concurrent threads, so replacing in the thread the socket code with sleep() is not true simulation of the problem. So I want to report the fix for the record: What fixes the problem is moving the threads->detach() on separate line! Thats all. (Long time ago I used to have the lines separate, but some Perl Guru told me it is not Perlish :(, but it worked until 5.8.2. BTW, I still have some instability problems that were not present in earlier version. Thanks all.
[reply]
      I have considered moving threads->detach() on a separate line before I made my original post though, but moving detach on to another line is not doing what you think it's doing. The following codes are not equivalent:
      threads->create(\&create_threads, "param")->detach();

      [download]
      and 
      threads->create(\&create_threads, "param");
threads->detach();

      [download]
      In the first example, detach() is performed on the object returned by threads->create(), which detaches the thread created. Moving detach() on a separate line does not detach the thread at all, calling threads->detach() separately has no effect on the thread you just created.

      The proof? Well, there is a threads->list() function that lists all non-joined, non-detached threads. Add threads->list() after threads->detach() showed that the created thread did not get detached at all.

      I agree there is definitely a bug with detach() on out of scope object, but moving detach() on a separate line is not a fix. You must call $thread_created->detach() to truly detach the thread.

[reply]
[d/l]
[select]
        Roger,

        Thanks again for your time and effort. Your help was to the point. Much appreciated.

        Alas, you were right that the threads were not detached, so Perl didn't crash as apparently the detach() causes it. With the proper detach(), even on separate line, Perl crashs again :(

        Also crashes if I move the detach to inside the thread

        threads->self->detach();

        Now if only AS will fix the problems in Windows Perl v5.8.2 soon or I will have to fall back to 5.8.0:(

[reply]

In Section Seekers of Perl Wisdom