httpd-modules-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Some Guy <teknos...@gmail.com>
Subject Re: Process lifetime and hooks to use
Date Wed, 21 Apr 2010 14:02:11 GMT
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 <alinachegalati@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 <teknosoul@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 <alinachegalati@yahoo.com
> >wrote:
>
> > why don't you create global variables and put there the configuration
> data?
> >
> >
> >
> >
> > ________________________________
> > From: Some Guy <teknosoul@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 <alinachegalati@yahoo.com
> > >wrote:
> >
> > >
> > >
> > > comments inline
> > >
> > >
> > >
> > >
> > > ________________________________
> > > From: Some Guy <teknosoul@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 <alinachegalati@yahoo.com
> > > >wrote:
> > >
> > > > It depends what you want to do in this hook.
> > > >
> > > > --- On Sun, 4/18/10, Some Guy <teknosoul@gmail.com> wrote:
> > > >
> > > > From: Some Guy <teknosoul@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.
> > > > <wrowe@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.
> > > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > >
> > >
> >
> >
> >
> >
> >
>
>
>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message