httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dean Gaudet <dgau...@arctic.org>
Subject Re: [PATCH] Complete fix for mod_example memory bloat
Date Sun, 04 May 1997 19:11:45 GMT
On Sat, 3 May 1997, Rodent of Unusual Size wrote:

> >From the fingers of Dean Gaudet flowed the following:
> >
> >On Fri, 2 May 1997, Rodent of Unusual Size wrote:
> >>     One thing that's different is that I'm storing the per-request stuff
> >>     in the r->request_config list, which appears to be only minimally
> >>     supported.  I haven't found anything in the archives (yet) that
> >>     indicates this is discouraged or deprecated.
> >
> >request_config has no defined API for promoting a request_config entry
> >from a subrequest to the main request.  Therefore is broken by
> >mod_negotiation.  I noted that when I submitted the last of the "promote
> >everything" patches.
> 
>     That shouldn't affect this, since the request_config stuff is being
>     stored explicitly in the main request.  That's the only place I hang
>     a request_config record.  If the current request is a sub, I go to
>     the main to find/store the request tree-wide record.
> 
>     Does that address the concern?

For mod_example yes, but not for the API in general.

> >For 2.0 it should either go away, or have a defined mechanism for
> >promotion. 
> 
>     I couldn't find any obvious other way for a module to maintain
>     request tree-wide internal data, which certainly sounds like a lack.
>     Of course, I'm still feeling my way through a lot of this stuff,
>     and maybe I missed something..?

There is r->notes, which is promoted from subrequests.  Otherwise yes it
is a lack in the API.

> >Oh yeah I forget if you note it, or if it's noted in the docs, but all
> >per_dir_configs should be considered "const" unless being modified by
> >the per_dir_merger or a configuration command handler (and only when
> >invoked by the core).
> 
>     I don't think I remark on that in the code/docs, so I'll add
>     something about it.  I'm not sure how a module is supposed to be
>     able to tell whether its command handler was invoked by "the core"
>     or not..?

What I'm trying to say is that it's probably not correct to call your
own merge function yourself so as to futz with the current request...
as an attempt to get per request data :)  It's certainly not defined.
It's only correct to modify your per_dir stuff when invoked through
the normal course of processing by the core code.

Dean


Mime
View raw message