serf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bert Huijben" <b...@qqmail.nl>
Subject RE: svn commit: r1713489 - in /serf/trunk: buckets/event_buckets.c outgoing.c serf_private.h
Date Tue, 10 Nov 2015 22:37:10 GMT


> -----Original Message-----
> From: Ivan Zhakov [mailto:ivan@visualsvn.com]
> Sent: dinsdag 10 november 2015 20:43
> To: rhuijben@apache.org
> Cc: dev@serf.apache.org
> Subject: Re: svn commit: r1713489 - in /serf/trunk: buckets/event_buckets.c
> outgoing.c serf_private.h
> 
> On 9 November 2015 at 20:49,  <rhuijben@apache.org> wrote:
> > Author: rhuijben
> > Date: Mon Nov  9 17:49:59 2015
> > New Revision: 1713489
> >
> > URL: http://svn.apache.org/viewvc?rev=1713489&view=rev
> > Log:
> > Replace the track bucket in the request writing with a tiny bit more
> > advanced event bucket that tracks both writing done and destroyed. The
> > timings of these callbacks will allow simplifying some logic introduced
> > in r1712776.
> >
> > For now declare the event bucket as a private type.
> >
> > * buckets/event_buckets.c
> >   New file.
> >
> > * outgoing.c
> >   (request_writing_done): New function.
> >   (request_writing_finished): Tweak to implement
> serf_bucket_event_callback_t.
> >   (write_to_connection): Add event bucket directly after the request
> bucket,
> >     instead of an aggregate when the writing is done.
> >
> Hi Bert,
> 
> What do you think about alternative design for event buckets: make
> event bucket wrap any other bucket (request bucket in our case)? I
> think it will be more flexible since we could add callback to be
> called before reading from wrapped bucket to track pending request.

That might work, but would have different characteristics unless you do more special things.

Currently the 'done' handler is called after reading the request from the bucket, while the
'finished' handler is called after it is destructed.

The done handler can be slightly rescheduled, but that *after* destructed moment is really
important. The old 'stream' implementation that didn't destroy buckets inside was a cover-up
for the problem that we didn't know when the bucket was destroyed, while it lived in a different
allocator.

I'm not sure if wrapping the request really improves things there... The aggregate bucket's
promises work really nice here: the event bucket is called once, while the reading from the
bucket is not slowed down in any way by introducing another layer of callbacks.


It might make the event bucket more generic, but I'm not sure if we really need that... This
scheduling of requests is mostly an implementation detail of our http/1.1 stack; related to
our queues of written and unwritten requests there. I don't think the event bucket is really
a bucket that we want to expose in our public api.

The 2.0 stack and other protocols will need different systems as they have to apply a level
of framing (and in case of http/2 also windowing) over the request buckets. I'm not sure which
http2 specific buckets we want to expose as reusable apis either.

	Bert


Mime
View raw message