Mailing-List: contact modules-dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: modules-dev@httpd.apache.org
Received-SPF: pass (athena.apache.org: local policy)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=yahoo.com;
  h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type;
  b=Z1GindrEUsD5bRInXGPt4LbV0utqV5zHxwDylwg4m7o3CnZkbW2yxvg/i6gDpasJprdcyijEepy/iLpCO05hB51tI3zc2P/eJ62ZsNjgyx6FKQNqjZCsRm/UHi5EhPjUeX15u5UA0lZYkYNp2OlIxbwM+zyed+HQypeCUqzL87A=;
Message-ID: <303850.41306.qm@web50708.mail.re2.yahoo.com>
References: <p2k47e6c43f1004181751h19d24aa3g5e20c09966e19c14@mail.gmail.com>
  <120632.3523.qm@web50704.mail.re2.yahoo.com>
  <v2l47e6c43f1004190504p92e47efcyf4f72118129550f8@mail.gmail.com>
  <377280.88925.qm@web50703.mail.re2.yahoo.com>
  <m2i47e6c43f1004201544ud772d61bu8fcb1d353459b3b5@mail.gmail.com>
  <45730.82430.qm@web50706.mail.re2.yahoo.com>
  <z2g47e6c43f1004210537x267bed9cxe46de30f105aa57f@mail.gmail.com>
  <769008.31452.qm@web50705.mail.re2.yahoo.com>
 <z2t47e6c43f1004210702k7a351688u94b031071f0cf9f7@mail.gmail.com>
Date: Wed, 21 Apr 2010 07:22:32 -0700 (PDT)
From: alin vasile <alinachegalati@yahoo.com>
Subject: Re: Process lifetime and hooks to use
To: modules-dev@httpd.apache.org
In-Reply-To: <z2t47e6c43f1004210702k7a351688u94b031071f0cf9f7@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-192019494-1271859752=:41306"

--0-192019494-1271859752=:41306
Content-Type: text/plain; charset=us-ascii

you can access the config in the child process too, but not in the monitor hook.

Below is a sample of global variables with the monitor hook:

typedef struct data_config_t {
   const char *sample_log_file_name;
   apr_file_t *sample_log_file_handler;
   
   int sample_time;
} data_config_t;

static data_config_t sample_config;

static int process_sampler (apr_pool_t* p)
{
     // do some work

     // note that you have access to the sample_config variable

     return OK;
}

//in the register_hooks handler put :
ap_hook_monitor(process_sampler, NULL, NULL, APR_HOOK_LAST);


________________________________
From: Some Guy <teknosoul@gmail.com>
To: modules-dev@httpd.apache.org
Sent: Wed, April 21, 2010 5:02:11 PM
Subject: Re: Process lifetime and hooks to use

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


--0-192019494-1271859752=:41306--