I think my understanding of the monitor hook is fine. I can just use the passed in pool as my context and use the userdata_set/get APIs as I periodically fetch / update a file. What I'll need to play with is to see how I can set this up as a configuration parameter. If the post_config hook gets called in the parent process with the apr_pool_t* passed in also being the same one that monitor gets, then that would work.
The child hooks I think are the issue when dealing with the various MPMs, but it might not be a problem anymore since I can just use the pool passed into child_init as the store for my lock and cache. Is the same pool passed in child_init accessible in the request handler via request->server->process->pool ? I see a lot of modules using these static variables and globals all over - is this safe? Aren't the modules existing in multiple process spaces? How does the author know which static variables are going to be safe to access in each hook? I guess any statics assigned in the child_init are safe to use in the request handlers and other threads spawned in the child_init. And for the parent process it's probably best to just use the pool? Thanks, SB On Mon, Apr 19, 2010 at 1:41 AM, alin vasile <alinachegal...@yahoo.com>wrote: > It depends what you want to do in this hook. > > --- On Sun, 4/18/10, Some Guy <teknos...@gmail.com> wrote: > > From: Some Guy <teknos...@gmail.com> > Subject: Re: Process lifetime and hooks to use > To: modules-dev@httpd.apache.org > Date: Sunday, April 18, 2010, 5:51 PM > > Ah great. I know what I should do with that. Any insight on the > differences in MPMs and what to watch out for? > > On Sun, Apr 18, 2010 at 12:22 PM, William A. Rowe Jr. > <wr...@rowe-clan.net>wrote: > > > On 4/18/2010 2:34 AM, alin vasile wrote: > > > the monitor hook gets only a pointer to an apr_pool_t structure. > > > > Take a look at apr_pool_data_* API's, that should provide you all of the > > context and persistence you need. > > > > You will never see anything about servers, connections or requests > because > > this is running in the *parent*, it is blissfully unaware of specific > > requests > > and is therefore immune from being hijaaked by remote code execution and > > less > > severe but destabilizing attacks on the request processing code itself. > > > > > > >
