apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From r..@covalent.net
Subject Re: [PATCH] Buckets: add copy function, ap_bucket_split_any(), etc
Date Fri, 08 Dec 2000 19:15:20 GMT

> > However, ap_bucket_split_any() is not yet right. If a caller says "split at
> > 10000", then it will probably fail because the read() won't read in that
> > much. You need to read enough buckets, until you read the bucket that
> > contains the split point. *then* do the split.
> I completely agree.  It was done this way because it was all OtherBill and I could
> get Ryan to agree to after a lengthy debate on new-httpd.

Nonsense.  I said you can't split a pipe or socket bucket, and I still
stand by that.  Greg is saying that if you have a list of buckets and the
split point is not in the first bucket this function fails.  Those are
two completely separate and distinct statements, and both are 100%
correct.  However, what Greg is really talking about is splitting a
brigade instead of a bucket, he just wants a brigade split function that
takes an offset instead of a bucket.  I have no problem with implementing
a function like that at some point.

> What *I* wanted to do was to make split a native function of sockets and pipes that
> just happened to be a little overloaded.   (See my original posting and the ensuing
> debate in the thread "Implementing split() on pipe buckets?", beginning 11/12.)

It is not possible to reliably split a pipe or socket bucket.  I have
explained why in the past.  When you provide a solution that covers every
boundary condition that I listed without modifying the bucket structure on
failure, we can implement this.  Until then, you are defining two
different definitions for the split function, which I have and will
continue to veto.

> The short-short version is that I wanted to change pipe_read() to pipe_readn($
> function that obeys the len parameter.  pipe_split() would pass in point as t$
> length to read, pipe_read() would pass in IOBUFSIZE.  It was fairly straightf$
>  Ryan disliked it because it cluttered the buckets code with "non-atomic"
> operations.  Personally, I couldn't see why the read() function was allowed t$
> non-atomic but the split() function was not.  But whatever.  I'll let you do $
> arguing this time.  =-)

I never said anything about non-atomic.  I said that you can not change
the definition of the split function based on the bucket type.  I will
continue to stand by that statement, because it is the only way to make a
sane API.  The split_any function is a compromise to allow module writers
to split any bucket type.  The fact is this function is not nearly as
simple as what was implemented, because it has to handle all of the
boundary conditions that were laid out when this discussion happened on
the new-httpd list, and as it is now this function does not.

Ryan Bloom                        	rbb@apache.org
406 29th St.
San Francisco, CA 94131

View raw message