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
