httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexei Kosut <>
Subject Re: [PATCH] buff.c bug fix
Date Sat, 25 Jan 1997 08:50:54 GMT
On Fri, 24 Jan 1997, Dean Gaudet wrote:


> I've been looking into this one.

Good! Glad someone has.

> So far I can see a definite bug in bcwrite().  It's probably due to
> the assumption that if r=write(f,b,n) then r is one of -1, or n unless
> f is non-blocking.  That isn't the case, all values -1 <= r <= n are
> possible for any f.  I notice later on in bwrite() that it also indicates
> that assumption... but the bwrite() code looks ok on my first reading.

Okay... the patch you provide seems to compile and run fine, although
I don't know if it fixes the problem. How about we put it into 1.2b5,
and I can email Henrik and ask him if he'd mind running his test again
on it?

On a related note... Henrik's other point: The flush that we call
before going into keep-alive state (waiting for another request)
causes performance problems (a lot of them, apparently) when
pipelining requests - but causes functional problems if not. We had
discussed checking to see if there was any input waiting to be read,
and if there was, not flushing, otherwise, flush away. Did anyone ever
look into this furthur, to the point of having a patch for it? I would
myself, but TCP and things like that aren't what I do
best. BTW, specifically, he's talking about the bflush() calls at
lines 1676 and 2145 of the current http_main.c.

Another thing he mentions about Apache is something I had always meant
to change, even back in 1.1... that Apache requires you to cut off a
kept-alive connection after a certain number of requests, and that it
defaults at five (which is a ridiciously low number, when you stop to
think about how the Web is currently). Originally, this was done
because (in an early development version of 1.1), Apache used the same
pool for all the requests in a connection, which could eat up quite a
lot of memory. This was, however, changed, and near as I can tell,
there's no real reason why we should keep it around. Ideally, we'd use
the NCSA model; KeepAlive On|Off (though we could support numbers as
well, for backwards compatibility - they'd be equivilent to "On"). I
suppose it's a bit late in the beta cycle to do that, but it's a
thought. Anyone?


Alexei Kosut <>      The Apache HTTP Server

View raw message