Re: svn commit: r1707087 - /httpd/httpd/trunk/modules/debugging/mod_bucketeer.c

[Jacob Champion <ch...@gmail.com>]

On 05/02/2017 10:14 AM, Ruediger Pluem wrote> On 04/28/2017 10:50 PM, 
Jacob Champion wrote:
>> ...why does the EOR bucket have memory ownership of a request_rec,
>> especially when its lifetime is not well defined? And why have we
>> put business logic into a finalizer? This is ringing all of my
>> memory management alarm bells.
> 
> This dates back to a long time ago
> (http://svn.apache.org/viewvc?view=revision&revision=327925) when we
> started to add async processing to httpd. We had the issue that we
> could not just destroy the request pool, once we "finished" the 
> processing of a request, because we could still have buckets and data
> created out of the request pool in the async processing of the
> filters. Hence the idea was to sent a special final request bucket as
> the very last bucket of a request that tells the filter that consumes
> the bucket (usually the core output filter) that no data for the
> request is coming down the filter stack and that it is now save to
> destroy the request pool. And in order to prevent that logic to be
> coded in the filter (when it just sees the bucket) it was put in the
> "finalizer" code of the eor bucket. You might find this strange, but
> IMHO we have this pattern to use cleanups for some business logic
> quite often in httpd and we tie a lot of this logic to the lifecycle
> of pools. So pools are not just a memory management tool, but also a
> lifecycle management tool.

Hi Rüdiger,

I just realized I hadn't responded to this; sorry! Thanks for the 
background.

I have been trying (slowly) to learn enough about the async processing 
chain to participate meaningfully in this discussion, but so far I 
haven't had the time to really dig in. My intuition is that, if pieces 
of the request are disappearing out from under the thread, something is 
wrong with the lifecycle dependency chain (and I've never seen finalizer 
dependencies work out very well in practice). But it's just an idle 
guess without more research.

AFAIK, this is one of the final blockers (if not *the* final blocker, 
fingers crossed) for the trunk autotesting system; hence my interest.

--Jacob