Re: cvs commit: squid3/src BodyPipe.cc BodyPipe.h

From: Alex Rousskov <rousskov@dont-contact.us>
Date: Tue, 14 Aug 2007 16:05:18 -0600

On Tue, 2007-08-14 at 09:54 +1200, Amos Jeffries wrote:
> > rousskov 2007/08/13 10:48:20 MDT
> >
> <snip>
> > The new code also keeps track
> > of the number of outstanding events and skips that number if the consumer
> > leaves.
> >
> > TODO: when AscyncCall support is improved, should we just schedule calls
> > directly to consumer? It could be a much cleaner solution than counting
> > pending calls and skipping them when needed.
> >
>
> You mean like client-streams was meant to be (I think, after only a few
> days reading the code and a bias from work on other real-time
> applications).
> Where only the tail gets event calls and read events pull as much buffer
> data through the chain as possible?

No, nothing that complex! Chains are evil :-).

BodyPipe is not a chain. It is a dumb connection/transport between two
independent but cooperating jobs: the body consumer and the body
producer.

Currently, BodyPipe asynchronously calls itself so that it can
synchronously call the consumer or the producer with the right
parameters when new data arrives, etc. This creates a problem if the
consumer is not there when (or changes after) the asynchronous call is
scheduled: The new consumer may get only some of the scheduled calls,
and things will not work well.

When asynchronous calls are no longer hacked on top of a
single-parameter Event, the above indirection will not longer be needed.
BodyPipe will be able to asynchronously call the consumer or the
producer with the right parameters. At that time, the committed fix, and
80% of current call wrapping functions will no longer be needed.

Alex.
Received on Tue Aug 14 2007 - 16:05:43 MDT

This archive was generated by hypermail pre-2.1.9 : Fri Aug 31 2007 - 12:00:05 MDT