httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <>
Subject Re: cvs commit: httpd-2.0 CHANGES
Date Wed, 13 Jun 2001 00:13:57 GMT
On Tue, 12 Jun 2001, Greg Ames wrote:

> 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?

Forget completely about MMAPs.  What about the case where the platform
doesn't support MMAPs?  This has nothing to do with optimizing for one
case or another.  This has to do with not leaking resources like a sieve.

> > 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.

Again, this hsa nothing to do with MMAP's.  This has to do with file
descriptors.  By allocating out of the main pool, you are keeping file
descriptors far longer than you should.

> > 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.

Well, I removed the original hack because some people had posted real
world examples where this was noticably 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.

My veto stands on this code.  We have documented on this list two other
mechanisms for removing this problem that do not leak file descriptors
like this.  This patch just regresses to a leak that we don't need.  I
will try to write the setaside logic later tonight for either files or
mmaps to help alleviate this problem.


Ryan Bloom               
406 29th St.
San Francisco, CA 94131

View raw message