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

> 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.

Aha! gotcha. I hope this is all commented in the code. I haven't got the
docs branch around to ICAP yet.

> 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.
>

Thanks
Amos
Received on Tue Aug 14 2007 - 16:26:44 MDT