Perl's threads are imperfect, heavy and require a particular way of working to get the best out of them. But if you need to share data between contexts of execution, they are usually far easier to program and use than the alternatives. They do not lend themselves well to encapsulation, but for many applications that doesn't matter because the infrastructure code required is minimal.I completely agree with your assessment of the state of perl5's threads.
I've found that if you architect your application such that the threads module is only imported where needed, it all works out nicely. (Does a lot of data-copying on each thread initialisation.)
I use Thread::Queue::Any with abandon, it works well. In limited circumstances, I even send complex objects (after having structured the objects such that re-bless and $obj->init($DATA) works in unit tests).
There are a variety of modules available on CPAN that deal with the problem of "FAT" threads, in a variety of ways (eg: cleaning up included modules, re-loading them as needed).I find message-passing (as in Thread::Queue and friends) to be much easier to reason about than shared-memory based solutions (at least in imperative languages like perl).
-David
In reply to Re^4: Parallel::ForkManager and vars from the parent script - are they accessible? (or do I need inter process communication?)
by erroneousBollock
in thread Parallel::ForkManager and vars from the parent script - are they accessible? (or do I need inter process communication?)
by isync
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |