I've got fairly heavy computations which I fork off. And in http://www.perlmonks.org/?node_id=494032 it says that its better to use real procs instead of threads on heavy things.
Can somebody explain, why!? Should I revert to threads? | [reply] |
I've got fairly heavy computations which I fork off. And in http://www.perlmonks.org/?node_id=494032 it says that its better to use real procs instead of threads on heavy things.
I've got a neighbour who boasted for years that she didn't have a mobile phone: didn't want one; didn't need one; they were just pointless technology, just for kids to waste money on ringtone downloads; another of modern life's annoyances to disturb her in restaurants and theatres.
Turns out she has been hyperoptic for years and refuses to wear glasses. Then someone bought her a mobile with large, clear buttons and she's never without it.
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.
If you have a brief description of the application, I'd be happy to suggest/post a starting point using threads and you can decide for yourself whether they are suitable for your purposes.
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.
| [reply] |
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
| [reply]
[d/l] |