Re^8: How to do parallel processing within mod

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

Comment on Re^8: How to do parallel processing within mod_perl

Replies are listed 'Best First'.
Re^9: How to do parallel processing within mod_perl by perrin (Chancellor) on Nov 15, 2007 at 17:07 UTC
I don't see how you could avoid having a lot loaded in a web situation. You can delay loading your own libraries, but things needed just to handle the persistent daemon itself (mod_perl in this case) have to be loaded. It's easy to see the benefits of COW for yourself. Move the libraries you use into a mod_perl startup phase and watch the free memory on your machine go up. It works.	[reply]