[EMAIL PROTECTED] wrote:
>
> -1. We have discussed this on list multiple times. The solution is to
> use the setaside pool argument that Greg Stein just added.
includes have been totally broken since April 29. My patch fixes
includes, so I believe
this patch qualifies as making progress toward a usable server.
I agree that the setaside idea has some merits, but it is slower for the
common case
(a few small files which turn into MMAPs) because it involves
re-allocating and
recreating the apr_blah_t structures. Shouldn't we be optimizing for
the common cases
rather than the basket cases?
> This patch is
> as bad as the original hack (using c->pool for files), because it creates
> a huge resource leak. Imagine a simple SSI file with twenty small
> included files, you just leaked 20 files until the end of the request.
How huge are 20 apr_mmap_t's? Big deal if they have to wait for the end
of the
request. and how common would it be to have 20 include files anyway?
I believe the patch which broke includes was attempting to handle the
case where the little apr structures could stay around indefinately, due
to keepalives. That doesn't happen with my patch.
> This gets worse if the number of included files is larger, and other
> modules may make the problem even worse.
>
Let's see some real world examples where this is noticeably bad.
Remember, apache.org has been running fine for ages using the connection
pool/lifetime for subrequests. I've removed any possible exposure to
the keepalive problem by always using the main request lifetime.
I would welcome a more elegant solution to the problem that actually
works, and doesn't slow down the typical use of server side includes.
Greg
