> -----Original Message-----
> From: Ivan Zhakov [mailto:[email protected]]
> Sent: zaterdag 14 november 2015 14:25
> To: [email protected]
> Cc: [email protected]
> Subject: Re: svn commit: r1714297 - in /serf/trunk: buckets/event_buckets.c
> outgoing.c serf_private.h
>
> On 14 November 2015 at 12:36, <[email protected]> wrote:
> > Author: rhuijben
> > Date: Sat Nov 14 09:36:08 2015
> > New Revision: 1714297
> >
> > URL: http://svn.apache.org/viewvc?rev=1714297&view=rev
> > Log:
> > Redefine the event bucket as a wrapping bucket, to remove dependencies
> on
> > implementation details on the 'aggregation' stream around the event
> bucket.
> >
> > Calculate total number of bytes read to increase event value.
> >
> > @@ -128,7 +215,7 @@ static void serf_event_destroy(serf_buck
> > const serf_bucket_type_t serf_bucket_type__event = {
> > "EVENT",
> > serf_event_read,
> > - serf_event_readline,
> > + serf_default_readline,
> Is it intentional? Why event bucket doesn't forward readline calls
> directly to wrapped bucket?
I don't see why you would use the event bucket when you are reading yourself,
instead of putting it in a write stream. And write streams typically don't use
readline. (They would typically use read or read_iovec depending on whether ssl
or compression/decompression is used)
Writing that function as a wrapper would require coding that function,
reviewing it and testing it, while I don't see any usecase where somebody uses
this function.
And in all current implementations/usages just using the default readline would
100% do the same thing without measurable performance degradation.
Same reason as why we never implement read_for_sendfile().... There is not a
single user in serf that would use it.
Bert