httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tony Finch <...@dotat.at>
Subject Re: [PATCH] tweaks to bucket read retcode feedback
Date Thu, 14 Sep 2000 02:07:08 GMT
Jeff Trawick <trawickj@bellsouth.net> wrote:
>
>  eos_bucket->read() returns not a normal apr_status_t but instead
>  AP_END_OF_BRIGADE
>
>  pipe_bucket->read() returns APR_EOF when the pipe has no more data

Good catch. There are actually some additional problems with pipe_read
which I will fix along with committing your patch. The pipe bucket
isn't quite doing the right thing with its read function at eof which
may not help -- I'll make it morph into an zero-length heap bucket
when it hits EOF which will avoid multiple reads from the empty pipe
as it passes down the filter chain. Filters have to allow for
zero-length buckets so this is OK. There's also a memory leak because
the old ap_bucket_pipe isn't free()d. In fact ap_bucket_pipes are
superfluous so I'll remove them entirely.

>It might be nice to remove the pipe_bucket from the brigade and turn
>pipe_bucket->read into next_bucket->read if there is no data left in
>the pipe_bucket.  I think there would be problems with this,
>though...  One ugliness would be that a single check in a filter for
>e->type == AP_BUCKET_EOS is insufficient... other buckets could turn
>into EOS while reading... Yuck.

Yes, it's bad in lots of ways. At the moment read may do something
similar to split, which is reasonably easy to understand. Changing it
so that it may also do something similar to AP_BUCKET_REMOVE is making
it even more hairy, plus note that what you would actually have to do
is morph the current bucket into a clone of the next one and then
remove the next one (rather than a regular AP_BUCKET_REMOVE) in order
to preserve the caller's bucket pointer.

Tony.
-- 
en oeccget g mtcaa    f.a.n.finch
v spdlkishrhtewe y    dot@dotat.at
eatp o v eiti i d.    fanf@covalent.net

Mime
View raw message