httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Ames <>
Subject Re: cvs commit: httpd-2.0 CHANGES
Date Tue, 12 Jun 2001 21:28:14 GMT 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, 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.


View raw message