httpd-modules-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From alin vasile <>
Subject Re: Process lifetime and hooks to use
Date Mon, 19 Apr 2010 21:00:19 GMT

comments inline

From: Some Guy <>
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



On Mon, Apr 19, 2010 at 1:41 AM, alin vasile <>wrote:

> It depends what you want to do in this hook.
> --- On Sun, 4/18/10, Some Guy <> wrote:
> From: Some Guy <>
> Subject: Re: Process lifetime and hooks to use
> To:
> 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.
> <>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.
> >

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