Re: Tidying up the deferred reads

On Tue, 11 Oct 2005, Adrian Chadd wrote:

> heh. Quick perusal: the comm layer knows about held/resumed FDs.
> In my code, the comm layer doesn't know. We kick the read resuming
> at the same point (storeClientCopy3()). The epoll() patch doesn't
> seem to require any changes to the store server side.
>
> I prefer mine because there wouldn't be any extra code to maintain/check
> the deferred fds. the epoll branch, however, does keep track of these FDs
> and it lets him make sure FDs don't "disappear" because IO isn't registered
> back for said FD.

Right.

I however think I prefer the comm layer being the main responsible for the
deferrals. This ensures it's done in the same manner for all the
protocols, and allows for less race conditions I think..

But ultimately there would be no need for deferrals at all, and this whole
thing being maintained by the store layer pulling data from the protocols
(or the client in uploads) rather than the protocols "blindly" pushing
data into the store. This however requires a fair bit or restructuring to
get it right. But maybe this is sort of what you are doing?

Regards
Henrik
Received on Fri Oct 14 2005 - 04:41:17 MDT