> 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
