Threads are generally not advisable in situations like mod_perl or FastCGI with Perl, because they take up a lot more memory than a prefork approach. They can be useful for short-lived things, but usually forking is less resource-intensive due to the non-shared nature of Perl threads and copy-on-write savings for forking. | [reply] [Watch: Dir/Any] |
Threads are generally not advisable in situations like mod_perl or FastCGI with Perl, because they take up a lot more memory than a prefork approach.
It really depends how you use them.
You can pre-thread just as easily as pre-fork. The threads needn't have anything you don't want loaded/cloned into them.
If you maintain a pool of threads for this kind of task, simply feed them using Thread::Queue.
They can be useful for short-lived things, but usually forking is less resource-intensive due to the non-shared nature of Perl threads and copy-on-write savings for forking.
I think the benefits of COW for the Perl 5 interpreter are vastly overstated by most people. Ask BrowserUK what he thinks of the situation.
-David
| [reply] [Watch: Dir/Any] |
| [reply] [Watch: Dir/Any] |