On Tue, Nov 10, 2015 at 4:44 PM, Bert Huijben <[email protected]> wrote: >...
> There is one more problem with all this wrapping: All layers need to > somehow support all read methods. > > Wrapping works for all methods except: readline. > If all methods are passed to the wrapped bucket, then readline works fine. > This method is only implemented on a few bucket types, and doesn't allow > passing an upper limit to whatever is read... so things like limit and > unframing buckets can never implement this without implementing some > caching... > > And once they introduce caching all read methods need to look at the cache. > Sure. That's what 'databuf' is all about. To implement that cache in a general way. Does it play nice with "limit" type buckets? Well, no... it overreads. Those buckets will need to be *much* smarter. I believe the correct answer is that limit-type buckets need to peek first, look for CR and/or LF, and then read() that much to return the caller. Limited, as appropriate. Because each read() will be preceded by a peek(), I think adding a peek_iovecs() can improve the performance. It can possibly provide more data to find that CR/LF. It's not required, but it might be a nice addition. I disagree with the recently-added readline2() because it's use is *so* minimal. It would be unfortunate to have two entry points with such similar signatures. We could add a utility function: serf_bucket_limited_readline() that is a cover over peek/readline. This problem is not that relevant for writing requests, as that reads raw > data anyway... but we are having more and more buckets that just set the > readline implementation to NULL. > Well, that was just them being lazy :-P ... I see you're fixing some of those buckets. Cheers, -g
