I haven't used threads before, but I found the following in perldoc threads for Perl 5.8.3 (typo corrected):

The context (scalar or list) of the thread creation is also the context for join(). This means that if you intend to return an array from a thread, you must use "my ($thread) = threads->new(...)", and that if you intend to return a scalar, you must use "my $thread = ...".

Now that I think about it, it kinda has to be that way. It can't use the context for the join call, because that's too late. The called routine has to be able to invoke wantarray from the moment it's called and get the right result.

Riiiiight, so this example from perlthrtut is rather misleading then:

Waiting For A Thread To Exit

Since threads are also subroutines, they can return values.  To wait
for a thread to exit and extract any values it might return, you can
use the join() method:

    use threads;

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

    @ReturnData = $thr->join;
    print "Thread returned @ReturnData";

    sub sub1 { return "Fifty-six", "foo", 2; }

In the example above, the join() method returns as soon as the thread
ends.  In addition to waiting for a thread to finish and gathering up
any values that the thread might have returned, join() also performs
any OS cleanup necessary for the thread.  That cleanup might be impor-
tant, especially for long-running programs that spawn lots of threads.
If you don't want the return values and don't want to wait for the
thread to finish, you should call the detach() method instead, as
described next.
[download]

Thanks!

I think the problem with perlthrtut and some other bits of the documentation (what there is of it), was mostly written for 5005threads and hasn't really caught up with ithreads yet.

That said. I'm not sure how the snippet you quote would have worked then either.

---

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, algoritm, algorithm on the code side." - tachyon

Patches are welcome. (Appreciated even.)

To make this discussion complete, on the other hand, most of the time, it is a better idea to return array ref, instead of array, regardless whether the program is multi-threaded: (In this way, you don't need to worry about the context any more)

use strict;
use warnings;
use Data::Dumper;
use threads;

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

my $ReturnData = $thr->join;
print Dumper($ReturnData);

$ReturnData = sub1();
print Dumper($ReturnData);

sub sub1
{
    return ["Fifty-six", "foo", 23];
}
[download]

This prints:

$VAR1 = [
          'Fifty-six',
          'foo',
          23
        ];
$VAR1 = [
          'Fifty-six',
          'foo',
          23
        ];
[download]

Sort of triggered by what CountZero and chromatic said, I tried this:

use strict;
use warnings;
use Data::Dumper;
use threads;

{
    my @ReturnData = sub1();
    print Dumper(@ReturnData);
}
{
    my $ReturnData = sub1();
    print Dumper($ReturnData);
}
{
    my $thr = threads->new(\&sub1);
    my @ReturnData = $thr->join;
    print Dumper(@ReturnData);
}
{
    my $thr = threads->new(\&sub1);
    my $ReturnData = $thr->join;
    print Dumper($ReturnData);
}
{
    my ($thr) = threads->new(\&sub1);
    my @ReturnData = $thr->join;
    print Dumper(@ReturnData);
}
{
    my ($thr) = threads->new(\&sub1);
    my $ReturnData = $thr->join;
    print Dumper($ReturnData);
}

sub sub1
{
    return wantarray ? (1,2,3) : [4,5,6];
}
[download]

Results:

$VAR1 = 1;
$VAR2 = 2;
$VAR3 = 3;
$VAR1 = [
          4,
          5,
          6
        ];
$VAR1 = [
          4,
          5,
          6
        ];
$VAR1 = [
          4,
          5,
          6
        ];
$VAR1 = 1;
$VAR2 = 2;
$VAR3 = 3;
$VAR1 = 3;
[download]

The result makes 100% sense under the current design, as it matches what the document said, the context (whether wantarray) has been already determined at the thread creation time.