[Unload module]

[Marin Cosmin <ma...@yahoo.com>]

Hello,

I'm working on an Apache module that will log some statistics in a file.
My problem is that I have no ideea about what should I do to unload the module.
In ap_hook_post_config hook I initialize some structures, use open() for some files ...
If I get an error during this phase how can I unload the module ?


Where should I destroy IPCS ? 
I used apr_pool_cleanup_register here but the behaviuor isn't the desired one.

Using apr_pool_cleanup_register in ap_hook_child_init seems to work.

Thank you.

Have a nice day/night !




       
____________________________________________________________________________________
Be a better Globetrotter. Get better travel answers from someone who knows. Yahoo! Answers - Check it out.
http://answers.yahoo.com/dir/?link=list&sid=396545469

Re: [Unload module]

[Joe Lewis <jo...@joe-lewis.com>]

Marin Cosmin wrote:
> Hello,
>
> I'm working on an Apache module that will log some statistics in a file.
> My problem is that I have no ideea about what should I do to unload the module.
> In ap_hook_post_config hook I initialize some structures, use open() for some files ...
> If I get an error during this phase how can I unload the module ?
>
>   

I'm not sure that unloading the module is a good idea. I'd suggest using
one of the *open_logs or *post_config hooks - and return an appropriate
error code if failure occurs. If you find that apache continues to load,
then you may want to set a flag in a configuration structure that you
can use to determine if you had success earlier. (For example, so that
you don't try to write statistics to a file that failed to open earlier).

> Where should I destroy IPCS ? 
> I used apr_pool_cleanup_register here but the behaviuor isn't the desired one.
>
> Using apr_pool_cleanup_register in ap_hook_child_init seems to work.
>   

That is where you want it - when the child starts, each child needs to
be able to clean up after itself, hence wait until the child starts to
register that one.

This is a bit more clear when comparing worker vs. prefork MPM's - each
child process has to take care of it's own in order to prevent memory
leaks, etc.

Joe
-- 
Joseph Lewis <http://sharktooth.org/>
"Divide the fire, and you will sooner put it out." - Publius Syrus