----- Original Message ----- From: "Stas Bekman" <[EMAIL PROTECTED]> Cc: "Ask Bjoern Hansen" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Thursday, November 28, 2002 11:07 AM Subject: default Content-Length calculation has been removed in 2.0 (was Re: mod_perl 2.x vs. mod_perl 1.x benchmarks)
> Actually, returning to Issac's question regarding releasing the handler > early, you need a slightly modified version of the cl filter to do that. > Since it's already buffering the data, you just want to do this > unconditionaly. How do you mean unconditionaly? BTW: I'm wondering whether the solutnio for the whole buffering thing is "write a buffer filter" or is this something that should be done internally within the brigades? After all, once the [mod_perl] response handler (or filter) passes the EOS bucket, it's not needed anymore, and who cares if the other filters are ready or not? Stas, it sounded to me like you were suggesting something like: mod_perl handler/filter--->Filter API--->buffer filter---->core-output---->client The assumption is that if bufer_filter slurps up the data, it will release the previous filters' resources, but I think that's kinda backwards thinking. As far as I understand, the only buffer you EVER have to worry about is the data coming IN to your filter. Once you pass the buckets along, you never have to worry about them again. 2 conclusions on this (my thought process included :-)): 1) The seemingly "correct" thing to do here would be to ensure that a handler/filter's resource pool (and entire thread?) is cleaned up as soon as it's done running. I think the latter is true, and to do this properly, Apache'd really have to give each filter plugged into each request it's own running thread. That's gonna add lotsa overhead. Maybe just a flag to request it's own thread if the module author/user is expecting their handler/filter to really use heavy resources (like an on-the-fly image processing filter for example). That way, heavy modules can get their own resources for when their eneded and release them ASAP. 2) The flipside of this is that a heavy module (like discussed above) *would* need this buffer filter; but it would want the buffer to slurp up the data coming *in*. The idea would be to let these heavy modules *create* themselves only when the data is ready (to optimize resource allocation/usage). The problem with this is that it's useless. Each request, as I understand, requires each filter in the chain to register itself in the bucket brigade chain right at the offset - which means that the "private thread" idea can't work since it will have to create the thread at the beginning of the request anyway - certainly before the data is ready. Comments? Issac
