httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tony Finch <...@dotat.at>
Subject Re: PLEASE READ: Filter I/O
Date Mon, 26 Jun 2000 04:28:11 GMT
> I think this is also true for linked filters: if a filter is passed
> a block of data that's unparsable because a syntactic element is
> missing its end (presumably because it'll be passed down in the next
> chunk) then it'll have to hold it back for next time. You end up
> with exactly the same problems that the hook scheme is designed to
> address from the start. The link scheme will have to aggregate
> blocks of data in order to fix this problem which implies copying.

Um. That's incoherent. I meant something more like:

> I think this is also true for linked filters: if a filter is passed
> a block of data that's unparsable because a syntactic element is
> missing its end (presumably because the end will be passed down in
> the next chunk) then the filter will have to hold back the start of
> the syntactic element for next time. The link scheme ends up with
> exactly the same problems that the hook scheme is designed to
> address from the start with its event-driven design. The existing
> link scheme will have to aggregate blocks of data in order to fix
> this problem which implies copying.

For an example of holding back part of a syntactic element for
processing next time around, see Greg's version of mod_gargle which
has space for a byte in its private data area. More complicated
filters will need more complicated holding spaces and will end up
re-re-re-implementing the iovec-like-thing that the hook scheme is
built on.

Tony.
-- 
f.a.n.finch    fanf@covalent.net    dot@dotat.at
458 the delicate dew drops of disgust

Mime
View raw message