Is there a way to force rsync to be monothreaded (ie to don't fork)?

[Jamie Lokier]

Matt McCutchen wrote:
> There are two forks on a local run: the sender forks off the generator,
> and the generator forks off the receiver.  You can eliminate the first
> fork by accessing either the source or the destination via ssh to
> localhost (or, equivalently, "support/lsh" in the rsync source tree).
> 
> The second fork is a bigger problem, as rsync's mode of operation relies
> on having separate generator and receiver processes.  There used to be a
> maintained patch "threaded-receiver.diff" that made the generator and
> receiver two threads in the same process instead of two separate
> processes (Jamie may have been referring to this patch), but Wayne
> discontinued it on December 15, 2006.

Yes, I was referring to that patch, in fact I use it every day in
production systems running uClinux (which doesn't have fork()).

There are some little problems with it, most notably rsync uses _huge_
stack, much larger than the default thread stack.  (The largest local
variable is 256kiB by itself!).

I have a local fix to make the thread stack larger.  It works quite
well, but still crashes occasionally and I'm not sure why.  (There's
no memory protection on uClinux).

Someone else posted here a few months that they had fixed the first
fork so local rsync works with threads too (only remote rsync works in
my version), and some of the stack usage problems by changing them to
mallocs.

It's unfortunate (but understandable) that the patch is discontinued.
It's useful for uClinux (my daily use), OpenVMS, and would be useful
step towards a native Windows version if anyone wanted one.

Threading might even perform better even on standard OSes where
threads are available, which is nearly all nowadays.

> but I'm guessing that updating it for rsync 3.0.0 would be a lot of
> work.  And I don't know if using threads instead of processes will make
> the Carbon implementation happy.  I can think of three other potential
> options:
> 
> (1) Look into having the forked-off receiver process re-"exec" itself so
> it becomes an independent process.  You'll have to find a way to carry
> over the command-line arguments, filter rules, and first file-list
> chunk.

It seems that finding all the right state to copy might be more work
than making the code thread safe?

-- Jamie