> > 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 _______________________________________________________________________________ Ryan Bloom [EMAIL PROTECTED] 406 29th St. San Francisco, CA 94131 -------------------------------------------------------------------------------
