Caching a value for the lifetime of a module: CLUELESS

[luca regini <lu...@gmail.com>]

My understanding about per server conf is that any structure allocated
in the server config handler should have a lifetime that is the same
as the one of the module. So the server config structure should be an
ideal place for caching values. Anyway in the following simple module
the dbg counter is correctly incremented only for requests made within
the same connection. When i close the brower, reopen it and make
another request, dbg is set to 0. I am clueless and don't understand
what is wrong with this code.
Thanks in advance for your attention,
Luca


typedef struct
{
	//apr_hash_t *url_ht;
	#ifdef DBG_print_cache
	int dbg;
	#endif

} server_config;



/* Declare the module name */
module AP_MODULE_DECLARE_DATA sds_debug_module;


static void log(char * log)
{
	fprintf(stderr,log);
	fflush(stderr);

}

static void *create_server_config(apr_pool_t *p,server_rec *s)
{
	server_config *sconf = apr_palloc(p,sizeof(*sconf));
	//sconf->url_ht= apr_hash_make(p);
	#ifdef DBG_create_server_config
	fprintf(stderr,"calling create_server_config \n");
	fflush(stderr);
	sconf->dbg=0;
	#endif
	return (void *) sconf;
}


static void print_cache(request_rec *r)
{
	#ifdef DBG_print_cache
	server_config *conf;
	conf=(server_config*)
ap_get_module_config(r->server->module_config,&sds_debug_module);
	fprintf(stderr,"DBG: %d\n",conf->dbg);
	fflush(stderr);
	conf->dbg++;
	#endif
}



static int cache_url_handler(request_rec *r, int lookup)
{
	print_cache(r);
	return DECLINED;
}


/* Register the filter function as a filter for modifying the HTTP
body (content) */
static void register_hooks(apr_pool_t *p)
{
    // cache initializer
    // cache handler
    ap_hook_quick_handler(cache_url_handler, NULL, NULL, APR_HOOK_FIRST);
    // cache filters
    // XXX The cache filters need to run right after the handlers and before
    // any other filters. Consider creating AP_FTYPE_CACHE for this purpose.
    // Make them AP_FTYPE_CONTENT for now.
    // XXX ianhH:they should run AFTER all the other content filters.
    //

}

/* Define the module data */
module AP_MODULE_DECLARE_DATA sds_debug_module =
{
  STANDARD20_MODULE_STUFF,
  NULL,                        /* dir config creater */
  NULL,                        /* dir merger --- default is to override */
  create_server_config,        /* server config */
  NULL,                        /* merge server config */
  NULL,                        /* command apr_table_t */
  register_hooks 	       /* register hook */
};

Re: Caching a value for the lifetime of a module: CLUELESS

[luca regini <lu...@gmail.com>]

That's exactly what happens and i learnt it the hard way :).

Now my next question is: is there any ideal place provided by the
apache API to allocate a shared memory object?
Is there any source code example of such a use case?

Thanks.
Luca

On Tue, 8 Mar 2005 10:11:57 -0500 (EST), Cliff Woolley
<jw...@virginia.edu> wrote:
> On Tue, 8 Mar 2005, luca regini wrote:
> 
> > My understanding about per server conf is that any structure allocated
> > in the server config handler should have a lifetime that is the same as
> > the one of the module. So the server config structure should be an ideal
> > place for caching values.
> 
> But actually, it's not an ideal place at all, for the very reason you're
> finding here.  I suspect what's happening to your code is that you're
> running up against the fact that each child process has its own copy of
> the server_rec and all of the server_config structures.  They are not in
> shared memory, they're just duplicated when the parent forks itself.
> Therefore these structures are really only meant to be written to by the
> parent at config time.  Writing to them after that point will result in
> inconsistent state across children.
> 
> --Cliff
>

Re: Caching a value for the lifetime of a module: CLUELESS

[Cliff Woolley <jw...@virginia.edu>]

On Tue, 8 Mar 2005, luca regini wrote:

> My understanding about per server conf is that any structure allocated
> in the server config handler should have a lifetime that is the same as
> the one of the module. So the server config structure should be an ideal
> place for caching values.

But actually, it's not an ideal place at all, for the very reason you're
finding here.  I suspect what's happening to your code is that you're
running up against the fact that each child process has its own copy of
the server_rec and all of the server_config structures.  They are not in
shared memory, they're just duplicated when the parent forks itself.
Therefore these structures are really only meant to be written to by the
parent at config time.  Writing to them after that point will result in
inconsistent state across children.

--Cliff