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 -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
