Re^6: How to do parallel processing within mod

Replies are listed 'Best First'.
Re^7: How to do parallel processing within mod_perl by perrin (Chancellor) on Nov 15, 2007 at 14:57 UTC
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]
Re^8: How to do parallel processing within mod_perl by erroneousBollock (Curate) on Nov 15, 2007 at 15:20 UTC
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]
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]