Thanks a lot! BrowserUk. You are really great!

I'm sorry in fact there are some typos such as exported function names and missing the "1;" at the end of test.pm, etc. I should've double check my post...

But I am really weak on this part. The syntax to specify the subroutine-name in threads->create is confusing to me. And I guess maybe the latest release has addressed this problem (passing subroutine-name as string instead of code-ref). I have another question about code ref. In fact, I want my code to deal with unknown subroutine name beforehand. Instead, the name may be given in a parameter file in XML like the following:

<thread>
    <module>module_name</module>
    <subroutine>subroutine_name</subroutine>
</thread>
[download]

A script reads the file and put modulename in var "$module" and subroutinename in "$subroutine". Then, what is the correct syntax to create a thread for "$subroutine"? I guess I have to use Module::Load to dynamically load a module first and then call threads->create to run a thread for a subroutine. Will this cause some problem?

And I rewrite 2nd part as follows. Please help. Thanks!

use threads;
use test;
 
my $thread=threads->create('forthread', (argument));
$thread->join();
exit(0);
[download]

package test;
 
require Exporter;
                               
our @ISA        =qw(Exporter);
our @EXPORT     =qw(forthread);
our @VERSION    =1.0;
 
sub forthread{
        my (argument)=@_;
my $thread=threads->create('another', (argument));
$thread->join();
        return 0;
} #forthread

sub another{
return 0;
} #another
[download]

With a Testit.pm that looks like this:

package Testit;
require Exporter;

our @ISA        = qw[ Exporter ];
our @EXPORT     = qw[ forthread ];
our @VERSION    = 1.0;

sub forthread{
    my ($arg)=@_;
    warn "forthread called with argument: '$arg'";
    return 0;
}

1;
[download]

And a test.pl that looks like this:

#! perl -w
use strict;

use threads;
use XML::Simple;
use Data::Dumper;

my $data = '
<cde>
 <thread>
  <module>Testit</module>
  <subroutine>forthread</subroutine>
 </thread>
</cde>
';
my $ref = XMLin( $data );
print Dumper $ref;

my $argument=1;

require $ref->{thread}{module} . '.pm';  ## Line A

my $thread=threads->create(
    \&{ $ref->{thread}{module} . '::' . $ref->{thread}{subroutine} }, 
+# Line B
    $argument
);

$thread->join();

exit(0);
[download]

I get the following output:

c:\test>test
$VAR1 = {
          'thread' => {
                      'subroutine' => 'forthread',
                      'module' => 'Testit'
                    }
        };
forthread called with argument: '1' at Testit.pm line 11.
[download]

The salient parts of this are lines A & B

1. require $ref->{thread}{module} . '.pm';

   This concatenates the module name from the XML with '.pm' and then requires the module.

   Omitting the '.pm' from the XML simplifies the next line, but you could include it if it was important. You'd just have to strip it away for the next bit.

2. \&{ $ref->{thread}{module} . '::' . $ref->{thread}{subroutine} },

   This builds a string from the module name and subroutine name:

   $ref->{thread}{module} . '::' . $ref->{thread}{subroutine}

   Note: It means you don't have to export the function from the module, thereby avoiding polluting your main, and the risk of conflicts where two more modules export the same subroutine.

   It then asks Perl to treat that string as the name of a subroutine by placing it inside &( ... }:

   &{ 'Testit::forthread' }
   [download]

   And finally (and subtly), it asks for a reference to that subroutine

   \ &{ 'Testit::forthread' }
   [download]

   Without the \, the &{ 'subroutine' } construct would immediately call the subroutine named, and it would be the return value from the subroutine that would be passed to threads->create(). Which wouldn't do at all. The backslash tells perl to not invoke the subroutine, but rather return a coderef to instead.

Interestingly, if you wanted to invoke the subroutine via the &{ ... } construct, and are useing strict, then you would have to disable strict for this with no strict 'refs';, as this is a symbolic reference. However, by asking for a coderef, it appears to bypass the strict detection mechanisms and lets you get away without disabling strict. I only discovered this because I reused your early code which didn't have strict enabled.

You might want to add the no strict 'refs'; anyway, as it would act as a warning/reminder that something unusual is going on here. Eg.

require $ref->{thread}{module} . '.pm';

my $thread=threads->create(
    do{
        no strict 'refs';
        \ &{
            $ref->{thread}{module} . '::' . $ref->{thread}{subroutine}
        }
    },
    $argument
);
[download]

Here the do{ .. } block serves to confine the effects of the no strict 'refs' to exactly that piece of code where it is(n't :) needed.

You could of course, assign the concatenated name to a variable and the substitute that variable for the string:

require $ref->{thread}{module} . '.pm';

my $subname = $ref->{thread}{module} . '::' . $ref->{thread}{subroutin
+e};

my $thread=threads->create(
    do{ no strict 'refs'; \ &{ $subname } },
    $argument
);
[download]

if you feel that clarifies things. Many here would, and looking again at the above, in this case I might agree with them.

---

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."

Wow, you must be a GURU:)
I really learned a lot! THANKS A MILLINION!

Another thing just came to my mind, it makes more sense to give PATH to module. So, we will have a PATH/modulename. "require" can handle a path, right? what about Module::Load, it seems to me there's ssome difference but not very clear ... Thanks!