[PATCH] Batch-mode rewrite
c.shoemaker at cox.net
Wed Jul 21 19:54:11 GMT 2004
On Tue, Jul 20, 2004 at 09:10:22AM -0700, Wayne Davison wrote:
> On Mon, Jul 19, 2004 at 06:18:49PM -0400, Chris Shoemaker wrote:
> > Ok, how about this: Instead of index notification, run the generator
> > and receiver serially.
> I had wondered about that too, but the problem is that the generator
> expects data from the receiver, so we'd need to add special code to
What data exactly? I thought:
1) all recv-to-gen communications went through the error_pipe fds.
2) the only meaningful communications were redo requests and
I thought we could skip the redos and fake the "I'm done". What am I missing?
> avoid this and also to separate the post-generator processing (the
> directory tweaks) would have to be delayed until after the receiver
> post-processing had finished (the --delete-after handling). I think
> I'd like to avoid that.
Ah, I see what you mean about the directory tweaks. AFAICT, this is
really easy to fix, though. I think it's nicer to break that tweaking
loop into its own function anyway, (independent of solving the read-batch
gen/recv sync problem.) I'm attaching a version of this gen/recv
serialization concept patch with the directory tweak in its own
Just to clarify, I don't have anything against the index notification style
gen/recv syncronization. If you think that's better, then let's go that
way. But, I think there should be some expected benefit to rsync as a
whole. I.e., I don't think read-batch should drive that decision.
My opinion is that the gen/recv serialization is a simpler solution to
read-batch gen/recv sync than the index notification. (Assuming I haven't
missed something important about gen/recv communication.) But, more
importantly, what's the simpler solution for all of rsync, in the
More information about the rsync