From: "Richard Hartmann" <[EMAIL PROTECTED]>
> for lack of a general list, I decided to send this to this list. I am
> not sure if it is not well outside the scope of this list, if so, I
> apologize.
I think you might have a better chance of a solution on perlmonks.org
> My smallish test case is as follows (beware potential GMail
> linebreaks..):
>
> #!/usr/bin/perl
>
> use strict;
> use warnings;
>
> use threads;
>
> use RPC::XML;
> use RPC::XML::Server;
>
> my $findserver = RPC::XML::Server->new(host => '0.0.0.0', port => '9000');
> my @signature= ('struct struct');
> $findserver->add_method({ name => 'request_info', signature =>
> [EMAIL PROTECTED], code => \&request_info });
> $findserver->server_loop();
>
> sub request_info {
> my $thread = threads->new(\&sleeper);
> $thread->join;
> }
>
> sub sleeper {
> sleep 2;
> }
>
>
> When sending an XMLRPC request with request_info to this server, Perl
> will die the hard way once you join() the thread. From the looks of it,
> Expat may be at fault. Alternatively, RPC::XML::Server might be to
> blame.
>
> Please do not go into threads-hate mode, I know there are issues with
> it, but I never encountered something like this. If you still feel the
> need to tell me how bad threads are, please provide a viable scenario
> where I dispatch a dozen workers that need to return output to the
> master, at some point. Although my example is blocking, the real code is
> not and I can not afford to block while waiting on a process.
The fact that they need to return something doesn't mean they need to
be in-process. You may open some pipe()s and fork off a few
processes.
I'm afraid that's about all help I can give you.
Jenda
===== [EMAIL PROTECTED] === http://Jenda.Krynicky.cz =====
When it comes to wine, women and song, wizards are allowed
to get drunk and croon as much as they like.
-- Terry Pratchett in Sourcery
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
http://learn.perl.org/
