httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dean Gaudet <>
Date Thu, 16 Apr 1998 05:41:13 GMT

On Wed, 15 Apr 1998, Marc Slemko wrote:

> I agree with Dean's comments; building static things once is where we need
> to be moving.  Not just for this, but for everything.  Long term, keeping
> nearly-fully cached response headers is even better.  If we do return a
> pointer to a static (the building of which needs to have a mutex for
> threaded platforms, no?) then we have to document it, but it isn't a big
> deal because we use pools so people aren't normally going around trying to
> free things anyway.

Yeah I've been trying to think of how I could extend SHARED_TIME to
include the Date: header pregenerated.  Roy, if you're listening, HTTP
could do with a TAI format date as an option, costs far less to generate.
(Well, actually HTTP could do with a binary version, I digress.)  Anyhow,
it's possible without any expensive locks.

The trick is to cycle through at least two buffers, and point at the
"current" set of correct headers.  Each buffer needs a semaphore so
that it can be reused when all the threads are done with it.  But it's
a multiple-reader, single writer situation, and by the time the writer
is interested it's already told new readers to go look at another buffer
instead... so there's almost no contention for the semaphore.

And you don't have to lock the pointer -- because the readers will read
the pointer and then try to get a read lock on the buffer pointed to.
If a reader blocks in between reading the pointer and locking the buffer,
it's still safe.  Because the writer could lock the buffer, blocking
out the reader until its done.

Unfortunately though you can't just use these preconstructed headers as
part of a writev(), each reader has to copy them.  This is because the
writev() has an unbounded time limit, and you don't want to have an
unbounded cycle of buffers.

I can probably work this into SHARED_TIME.

But yeah it's worth 1 to 2% probably -- strftime() shows up fairly high
in the profile.


View raw message