As far as I know, Support for PerlThreads is minimal, since they don't work all too well. See my explanation here. Anyway, I doubt ANY perl modules are threadsafe since 1) none of them say anything about it and 2) people have seemed to have given up on PerlThreads :-( The only exception I can think of is perlxs modules which link to threadsafe C libs- OK there. Remember, a lib is only threadsafe if it explicitly says so. If you desperately need threads, I offer a pseudo solution in the link above. You have some options to make libraries threadsafe
- Go through all the code and lock global variables
- Go through the code and nuke globals replacing them with refs in passed args to vars in the calling function (a more C-ish solution and one recommended by the POSIX standard)
- Allow only one thread at a time to access the library (mutex fr the whole library)
Keep in mind that Perl muteces are far from bulletproof and it is likely that you'll come across some potholes in the threads if you do anything more than perform simple operations. In fact, this is a failing I'm working on right now. You did mention before wanting to compile this, so I hope perl2exe does this well (I have no idea) and I hope you know what you're doing. Good luck!
AgentM Systems nor Nasca Enterprises nor
Bone::Easy nor Macperl is responsible for the
comments made by
AgentM. Remember, you can build any logical system with NOR.
| [reply] |
3.Allow only one thread at a time to access the library (mutex fr the whole library)How would one do this? Obviously I am not a thread master, but I have an almost infinite capacity for frustration, which serves me as well as my caffine addiction and my distaste for sleep. However, I really want to work with threads. What is the interface for using ithreads, and where is it documented? Is this different from using Thread.pm?
_______________________________________________
"Intelligence is a tool used achieve goals, however goals are not always chosen
wisely..."
| [reply] |
Good question. In Perl, this is difficult since the Threads.pm muteces are exactly what's holding PerlThreads back in the stone age. I'm working on a fake mutex that uses flock on some file. Read more about the difficulties with flock here. In the meantime, just flock the library or some arbitrary file everytime you wish to access the file. Keep in mind that this defeats any use of threads within that library- only one thread at a time may access it and your thread stacks may expand greatly. I'll keep you posted on my own efforts as well. Good luck!
AgentM Systems nor Nasca Enterprises nor
Bone::Easy nor Macperl is responsible for the
comments made by
AgentM. Remember, you can build any logical system with NOR.
| [reply] |
Java has support for threads built-in. My college textbook Software Construction with Examples in Ada treats threads as an important concept in CS. It advocates first decomposing a system into its different concurrent processes, and then writing threads to perform the different processes.
A similar textbook "with examples in Perl" would therefore be an impossibility.
In real life perlmonks.org is multi-threaded. Each of us reading and posting is in real life a thread. An inability to support threads could choke Perl's future growth.
So the question is, should Perl support threads? How much of a deficiency is this inability to write threaded programs using Perl?
| [reply] |
FYI different posters are much
more akin to separate processes than separate threads.
Also there is no realistic hope that a sane threading
model can be reverse-engineered onto Perl before 6.0.
Please see Threads vs Forking (Java vs Perl) for more.
| [reply] |
