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.
> > >
> >
> >
> >
> >
> >
>
>
>
>
>
