[Mod_gzip] Cleanup and Init in Mod_gzip
Ian Holsman
mod_gzip@lists.over.net
Thu, 18 Mar 2004 10:29:51 +1100
Hi Guys.
I'm not really that familiar with the 1.3 codebase, but inside apache
2.0 the following would be the answers (they probably apply to 1.3 as well)
1. post_config hook being run twice.
this is a known 'feature'. someone posted a macro on
dev@httpd.apache.org which could be used to run your code only once.
the static variable should work, is this the hook you are using to try
to initialize your code?
2. cleanup routines
these should be registered via apr_pool_cleanup. If you want your code
to be called at the end of the process, than the pool passed to the
init_child should be the one you are after. The pool code in 1.3 is
similiar to 2.0's (just the names have been changed) if you search for
'cleanup' you might find the old function name.
Hope this helps.
Ian.
ps.. a good list to ask your module-development questions would be
http://modules.apache.org/subscribe
Tejas Sumant wrote:
> Hi Michael,
>
> We have our own compression card. We want to bypass software
> compression done using mod_gzip. We are mapping device memory
> to module memory and this I want to do when module get loaded.
>
> Simillarly unmapping is desired at unloading time.
>
> So I want to add some code in mod_gzip.
>
> I checked all hooks available with Apache 1.3.
> But none I found useful for my purpose.
> There is module_child_init hook, but I want a hook called at
> load time and not when a child is created.
> Second one is module_child_exit. The is same as child_init.
> I want a hook at the time of exit.
>
> Regards,
> Tejas
>
>
>
> ----- Original Message -----
> *From:* Michael.Schroepl@telekurs.de
> <mailto:Michael.Schroepl@telekurs.de>
> *To:* mod_gzip@lists.over.net <mailto:mod_gzip@lists.over.net>
> *Cc:* tejas@indranetwroks.com <mailto:tejas@indranetwroks.com>
> *Sent:* Tuesday, March 16, 2004 9:19 PM
> *Subject:* Re: [Mod_gzip] Cleanup and Init in Mod_gzip
>
>
> *Hi Tejas,*
>
>
> *> *Q. 1) I want to call my cleanup function when then module gets*
> *unloaded
> *> *or at resrtart or shutdown of Apache server.
> *> *Please can anyone tell me, where should I call my cleanup
> function* *from?
>
> *inserting your code into a third-party module seems an*
> *awkward way of handling whatever problem you have,*
> *instead of just implementing your own module.*
>
> *So I would rather suggest to think about a different way*
> *of doing whatever you want to do, as it might be much*
> *easier then.*
>
> *Which kind of "cleanup" do you have in mind so that you*
> *want to bundle it to the availability of mod_gzip?*
> *If it were something that would improve the operation*
> *of mod_gzip itself you might as well formulate a feature*
> *request; and if not, inserting the code into mod_gzip*
> *might be a bad idea as you could possibly have to*
> *maintain your modification in all future versions.*
>
> *I am not aware of any way to unload a module except*
> *for restarting Apache, so if you want to handle this case*
> *(whichever hook the Apache API might provide for this*
> *purpose) then you would likely have your solution already,*
> *and it would be completely outside the mod_gzip code.*
>
> *> *Q. 2) mod_gzip_init function gets called twice when server starts.
> *> *I want to call my init funtion from within mod_gzip_init.
> *> *As mod_gzip_init is getting called twice my init function is
> *> *getting called twice, which is undesirable.
> *> *I declared a static variable with initial value 0 and incremented
> *> *for each call. But this technique also failed. Please can anyone
> *> *tell me solution.
>
> *I don't know too much about the Shambhala API*
> * (http://httpd.apache.org/dev/API.html)*
> *but I would guess that the "init" function might receive*
> *parameter values from where it is able to find out which*
> *one of these two invocations is taking place at the moment.*
> *So this is where I would try to look at first.*
>
> *I don't think your implementation should modify the*
> *mod_gzip code - you are about to create an unnecessary*
> *dependence here.*
> *Perhaps you should discuss your problem with the Apache*
> *Group so that they could show you the Apache hook most*
> *appropriately for your purpose.*
> *Regards, Michael*