serf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@gmail.com>
Subject Re: svn commit: r1713489 - serf_bucket_readline()
Date Wed, 11 Nov 2015 16:54:41 GMT
On Wed, Nov 11, 2015 at 10:51 AM, Bert Huijben <bert@qqmail.nl> wrote:

>
>
> > -----Original Message-----
> > From: Ivan Zhakov [mailto:ivan@visualsvn.com]
> > Sent: woensdag 11 november 2015 13:22
> > To: Bert Huijben <bert@qqmail.nl>
> > Cc: rhuijben@apache.org; dev@serf.apache.org
> > Subject: Re: svn commit: r1713489 - serf_bucket_readline()
> >
> > On 11 November 2015 at 01:44, Bert Huijben <bert@qqmail.nl> wrote:
> > >> -----Original Message-----
> > >> From: Bert Huijben [mailto:bert@qqmail.nl]
> > >> Sent: dinsdag 10 november 2015 23:37
> > >> To: 'Ivan Zhakov' <ivan@visualsvn.com>; 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
> > >> > -----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.
> > >
> > > 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.
> > >
> > How is event bucket situation different from barrier bucket for example?
>
> The event bucket currently doesn't forward a single read method, while the
> barrier forwards all?
>
>
> Let me reverse the question: what makes them similar?
>
> I think there are two classes of buckets: one that wrap other bucket(s) in
> some way or another and others that don't.
>
> The current event bucket falls in that last category, just like the
> simple, the iovec, the memmap, the file and the socket buckets (and
> probably a few others).
>

Sure, but you could use one callback when the wrapped bucket hits EOF, and
the other callback when the wrapper is destroyed.

A wrapper can be more efficient, as a content bucket generally requires an
aggregate bucket to attach that content to <whatever>.

Cheers,
-g

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message