Secondary Navigation

SOAP::Lite and threads

Hi, I have sent already this message to Perl-XML, but this one is probably more appropriate. The thing is, I m trying to build an app with two threads, using

Message 1 of 6
, May 28, 2001

Hi,
I have sent already this message to Perl-XML, but this one is probably
more appropriate.

The thing is, I'm trying to build an app with two threads, using
perl5.6.1 with the thread option on RedHat 7.0. Each thread calls a
different SOAP service; both use SOAP::Lite.

The app mostly crashes, but sometimes issues an error like this one:
XML::Parser is not available and XML/Parser/Lite.pm did not return a
true value at /usr/local/lib/perl5/site_perl/5.6.1/SOAP/Lite.pm line 806
thread 1.
I have looked at that subroutine, and looks like it's the one that
select XML::Parser::Lite if the other one is not available. I have tried
to modify it, adding :locked:method, and it still crashes, and now
sometimes it locks.

Question is, is SOAP::Lite thread safe? Should it be? Can it be? Maybe
using an alternative parser will make it so?

... Maybe ... OK, OK, maybe the question was not well made. A better way to ask would be: what parts of SOAP::Lite are, or should be, thread-safe? For

Message 2 of 6
, May 28, 2001

> Question is, is SOAP::Lite thread safe? Should it be? Can it be?

Maybe

> using an alternative parser will make it so?
>
> Thanks for any answer...

OK, OK, maybe the question was not well made. A better way to ask
would be: what parts of SOAP::Lite are, or should be, thread-safe? For
instance, maybe new is not, but call is... so that we can put "new"
calls outside threads, and calls within threads. Is there any
documentation on the subject? Any way to know other than ask?

J

jmerelo@geneura.ugr.es

OK, OK, I can hear you all: do your homework, man, read the FAQ, RTFM, go to school, and that s what I did: I separated the creation of the soap object

Message 3 of 6
, May 28, 2001

OK, OK, I can hear you all: do your homework, man, read the FAQ, RTFM,
go to school, and that's what I did: I separated the creation of the
soap object (outside the thread) from the call to the SOAP object
(within the thread). Now the error I have is:

And HTML::HeadParser is there allright, and in the path; looks like
the non-thread-safe part is maybe in LWP. Maybe it all boils down to:
is LWP thread-safe? And the answer is probably not? Can/should it
be?... welll...

Any other answer (coming from others apart from myself) will be
greatly appreciated)

Thanks!

J

Philip Molter

... Probably not is the answer to both. The thing you have to remember about threads in Perl is they re still highly experimental. In fact, unless you

Message 4 of 6
, May 28, 2001

On Mon, May 28, 2001 at 06:10:53PM -0000, jmerelo@... wrote:
: And HTML::HeadParser is there allright, and in the path; looks like
: the non-thread-safe part is maybe in LWP. Maybe it all boils down to:
: is LWP thread-safe? And the answer is probably not? Can/should it
: be?... welll...

Probably not is the answer to both. The thing you have to remember
about threads in Perl is they're still highly experimental. In fact,
unless you compile the perl binary just right (even with thread
support), even the examples that they give in the thread tutorials
won't work. Knowing Redhat's history with Perl, I would say it's
probably not. There's also currently no real good documentation on
which Perl modules are threadsafe, primarily because no one is using
them in any serious production work (again, through the warning in the
thread tutorials).

It's just not a good idea to use threads with Perl. Threading won't be
fixed in the 5.6 maintenance series. It might be fixed in 5.7. It
will definitely be written into Perl 6 correctly.

Hi, Philip! Unfortunately my impression is very similar to that. I was working with threads since 5.005 on many different platforms and results are not very

Message 5 of 6
, May 28, 2001

Hi, Philip!

Unfortunately my impression is very similar to that. I was working
with threads since 5.005 on many different platforms and results are
not very pleasant. In most cases script just died with diagnostics
that it couldn't find module that is definitely there and any attempt
to debug it just showed different result every time (it's not a very
straightforward to debug threaded app). I end up with writing
FakeThread module that emulated thread syntax (async, join, detach,
eval, etc.) and at least I don't need to rewrite script if threads
are not supported or I don't want them to be real. I also used
semaphores to regulate number of running threads and in most cases
one thread is running just fine :)) and more than one crash in
unpredictable places (even in different on different runs).

I still hope it'll work out, but for now all my tries to run it in
threaded mode (with 5.6, 5.6.1) were not successful so far.

> On Mon, May 28, 2001 at 06:10:53PM -0000, jmerelo@...
> wrote:
> : And HTML::HeadParser is there allright, and in the path; looks
> like
> : the non-thread-safe part is maybe in LWP. Maybe it all boils down
> to:
> : is LWP thread-safe? And the answer is probably not? Can/should it
> : be?... welll...
>
> Probably not is the answer to both. The thing you have to remember
> about threads in Perl is they're still highly experimental. In
> fact,
> unless you compile the perl binary just right (even with thread
> support), even the examples that they give in the thread tutorials
> won't work. Knowing Redhat's history with Perl, I would say it's
> probably not. There's also currently no real good documentation on
> which Perl modules are threadsafe, primarily because no one is
> using
> them in any serious production work (again, through the warning in
> the
> thread tutorials).
>
> It's just not a good idea to use threads with Perl. Threading
> won't be
> fixed in the 5.6 maintenance series. It might be fixed in 5.7. It
> will definitely be written into Perl 6 correctly.
>
> In short, don't use threads in Perl. Fork/exec.
>
> * Philip Molter
> * DataFoundry.net
> * http://www.datafoundry.net/
> * philip@...
>
> To unsubscribe from this group, send an email to:
> soaplite-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to
> http://docs.yahoo.com/info/terms/
>
>

__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - buy the things you want at great priceshttp://auctions.yahoo.com/

Juan Julian Merelo Guervos

... Well, it might, but I couldn t even compile a threaded version of 5.7.1 (see my post in comp.lang.perl.misc...) ... I think that s too bad... I don t know

Message 6 of 6
, May 29, 2001

> It's just not a good idea to use threads with Perl. Threading won't
> be
> fixed in the 5.6 maintenance series. It might be fixed in 5.7. It
> will definitely be written into Perl 6 correctly.
>

Well, it might, but I couldn't even compile a threaded version of 5.7.1
(see my post in comp.lang.perl.misc...)

> In short, don't use threads in Perl. Fork/exec.
>

I think that's too bad... I don't know if threads in python work
correctly, but if they do, it will be an even better alternative to
PERL. Not to mention Java. Besides, making a module thread-safe is not
so difficult, it's just a matter of being careful with global variables,
mainly. Too bad...