httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From c...@decus.org (Rodent of Unusual Size)
Subject Re: [PATCH] Complete fix for mod_example memory bloat
Date Sat, 03 May 1997 11:57:19 GMT
>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 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..?

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

    #ken    :-)}

Mime
View raw message