httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <>
Subject Re: Filtered I/O ... again. :-)
Date Wed, 31 May 2000 16:40:26 GMT
On Wed, 31 May 2000 wrote:
> The Approach:
> The hooks code that we currently have is very good, but not quite right
> for filters because it is all server-wide in scope.  The first thing I did
> was fix that by adding more hooks logic.  We now have RHOOK macros (a one
> to one relationship with HOOK macros) which attach a hook to the request
> rec.
> Moduleys still use ap_r* to output data, but in the apr* function, that
> data is copied into a new char (to keep it from being const), and the data
> is then passed through all of the filters before it is written out.
> It is possible to register a function for a hook at anytime while serving
> a request.  I have a module that currently inserts a filter during the
> fixups phase based on the request issued.  This also means that different
> requests can use different filters.  :-)

Some issues that I see right off the bat, which I believe are
architectural, rather than "we can fix later":

1) no way to create a specific ordering since it is a "broadcast" via the
   hook metaphor

2) an additional alloc/copy is occurring for every byte written

3) if the hook signature is altered (to an iovec or to ptrs) to allow each
   hook to adjust the length of the data, then we get even more alloc/copy

Each of these is addressed in a clean fashion by the design the I proposed
on April 14 (subject "Re: I/O filtering in 2.0", message ID of

1) solved by a linked list (i.e. ordered)
2) if no layers exist, then the (const) buffers are passed right to
3) the layer_func_t can pass the buffer to ap_lwrite() unchanged, or it
   can process it as it goes. copies are not necessarily required.

I get the sneaky feeling that I'm going to have to write an actual patch
reduce my design to code for actual demonstration purposes :-)


Greg Stein,

View raw message