httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Hyde <>
Subject Re: I/O filters & reference counts
Date Tue, 29 Dec 1998 16:50:01 GMT

There are two problems that reference counts address that we have,
but I still don't like them.

These two are: pipeline memory management, and response paste up.  A
good pipeline ought not _require_ memory proportional to the size of
the response but only proportional to the diameter of the pipe.
Response paste up is interesting because the library of clip art is
longer lived than the response or connection pool.  There is a lot to
be said for leveraging the configuration pool life cycle for this kind
of thing.

The pipeline design, and the handling of the memory it uses become
very entangled after a while - I can't think about one without the
other.  This is the right place to look at this problem.  I.e. this
is a problem to be lead by buff.c rework, not alloc.c rework.

Many pipeline operations require tight coupling to primitive
operations that happen to be efficient.  Neat instructions, memory
mapping, etc.  Extreme efficiency in this pipeline makes it desirable
that the chunks in the pipeline be large.  I like the phrase "chunks
and pumps" to summarize that there are two elements to design to get
modularity right here.

The pasteup problem - one yearns for a library of fragments (call it a
cache, clip art, or templates if you like) which then readers in that
library can assemble these into responses.  Some librarians like to
discard stale bits and they need a scheme to know that the readers
have all finished.  The library resides in a pool that lives longer
than a single response connection.  If the librarian can be convinced
that the server restart cycles are useful we get to a fall back to

I can't smell yet where the paste up problem belong in the 2.0 design
problem.  (a) in the core, (b) in a module, (c) as a subpart of the
pipeline design, or (d) ostracized outside 2.0 to await a gift (XML?)
we then fold into Apache.  I could probably argue any one of these.  A
good coupling between this mechanism and the pipeline is good, limits
on the pipeline design space are very good.

   - ben

View raw message