httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Roy T. Fielding" <field...@kiwi.ICS.UCI.EDU>
Subject Re: Yikes
Date Mon, 21 Apr 1997 21:27:33 GMT
>> Just a guess, but the memory leak is probably due to the example
>> trace being added to a server or cmd pool instead of a per-request pool.
>> I guess this is a good example of what not to do in a module.  ;-)
>> Seriously, though, if we can track down which of the handlers is
>> causing the bloating, it might be worthwhile to check the other modules
>> to see if the same thing is causing bloat elsewhere.
>Can you expand on what _not_ to do here? I still have a serious 
>growth problem here, and your comments seem to touch on what I am 
>seeing happen.

Not much -- I haven't needed to write a module yet, so I'm just guessing
as to what could go wrong based on how the core code is written.
Basically, the only pools that are safe to allocate from on a per-request
basis are the ones inside the request structure (and its sub-requests)
and the ones that are allocated and destroyed before returning.

>From a future API standpoint, what is currently missing is an additional
per-server global pool that is created and destroyed on each request.
That would allow server modules that do not have access to the request
pool (e.g., before the request is allocated or after it is destroyed)
to allocate memory without causing the server process to bulge.


View raw message