[PATCH] Batch-mode rewrite

Chris Shoemaker 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'm done".

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

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
long-term?

-chris

> 
> ..wayne..


More information about the rsync mailing list