Alin, Thank you for your time, patience, and help. I guess I'm still a little confused on the mechanism used to move the data from the configuration to a place that the monitor hook could use. I can only access the config in the parent process via the post_config hook (or am I wrong?).
If that's the case, then I need to store the variables in some static global field. However, the data that the post config hook gives me might come from a pool that gets cleaned, so I need a way to make sure the global fields aren't dangling. That's why I was considering making my own independent pool and duplicating the variables so I can store it into global variables without worrying about their lifetime. Their life would be based on the independent global pool that I create in the post config hook / monitor hook (whichever comes first). SB On Wed, Apr 21, 2010 at 9:25 AM, alin vasile <alinachegal...@yahoo.com>wrote: > you can use the memory pool passed to the monitor, but that pool never gets > cleaned, so you'll have to make sure that there are no memory leaks. > the docs don't say anything if the monitor hook runs after post_config... > > > > > ________________________________ > From: Some Guy <teknos...@gmail.com> > To: modules-dev@httpd.apache.org > Sent: Wed, April 21, 2010 3:37:47 PM > Subject: Re: Process lifetime and hooks to use > > I need to get it from the configuration file. If the post config hook runs > prior to the ap monitor hook, then that would work. But what memory is all > of that data allocated from? I don't want them disappearing on me. > > On Wed, Apr 21, 2010 at 4:22 AM, alin vasile <alinachegal...@yahoo.com > >wrote: > > > why don't you create global variables and put there the configuration > data? > > > > > > > > > > ________________________________ > > From: Some Guy <teknos...@gmail.com> > > To: modules-dev@httpd.apache.org > > Sent: Wed, April 21, 2010 1:44:06 AM > > Subject: Re: Process lifetime and hooks to use > > > > Thanks for your comments. Is a possible solution to the configuration > > problem to keep a global reference to a pool that I create (w/o a > parent)? > > I can then use that pool to duplicate some of the string data I need from > > the configuration and store those in my globals as well. > > > > I'll need to think of a way to document the code so people know what the > > heck I'm doing too. People who aren't familiar with apache modules are > > going to think I'm on crack. > > > > SB > > > > On Mon, Apr 19, 2010 at 5:00 PM, alin vasile <alinachegal...@yahoo.com > > >wrote: > > > > > > > > > > > comments inline > > > > > > > > > > > > > > > ________________________________ > > > From: Some Guy <teknos...@gmail.com> > > > To: modules-dev@httpd.apache.org > > > Sent: Mon, April 19, 2010 3:04:02 PM > > > Subject: Re: Process lifetime and hooks to use > > > > > > 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. > > > >>[alin vasile] the pool is used to allocate the memory from. You'll > need > > > global variables to store the pointers. See Nick.s response > > > > > > 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. > > > >> [alin vasile] I'm not sure of that. > > > > > > 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? > > > >> [alin vasile] You can't init static variables in child_init. don't > > > declare them static and, if needed, protect their read/write with locks > > > > > > 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. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
