Re: Unloading a perl module

[Arguile]

Better to declare them in httpd.conf or a startup.pl type script.

# httpd.conf
PerlModule Date::Manip

# or startup.pl
use Date::Manip ();

This allows them to be cached on server boot and shared between child processes. The () after the module in startup.pl is very important as it means the module won't polute your global namespace (exports nothing).

This gives you the performance advantage of having the module already compiled and cached, while keeping your memory requirements (per child) down. Make sure to still use the module in your hanlder/script though; while not always nesseccary it gets pretty confusing if you don't.

If you're running Apache::Registry or PerlRun the rules are slightly different. Check the guide for more info.

[mce]

Hi,
After a quick supersearch, I came up with this node
---------------------------
Dr. Mark Ceulemans
Senior Consultant
IT Masters, Belgium

[ehdonhon]

I've tested this in the past. I found that even if you don't have a startup.pl and just let your cgi scripts use the modules, they still get loaded into global namespace to be shared by all the children. I didn't do a lot of testing in this area, so your results may vary. If they do, I'd love to hear more about it.

[jepri]

The manual states (IIRC) that modules are shared until you modify internal variables, and then they become specific to the process that modified the variable. So as long as you don't keep state in the modules (few do) you will be getting the most efficient treatment.

____________________
Jeremy
I didn't believe in evil until I dated it.

[perrin]

This is only true if your CGI scripts get loaded during startup, i.e. any modules you load and any modules they load during server startup will be shared via copy-on-write.