Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Subject: RE: rsync local dir copy hang - solved for me
Date: Fri, 24 Oct 2003 07:41:54 -0700
Message-ID: <407DF7D68DD30440B5CEB70ED234D1CF03F871F6@excuswa100.americas.unity>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
From: "Bakken, Luke" <Luke DOT Bakken AT getronics DOT com>
To: "Hannu E K Nevalainen" <garbage_collector AT telia DOT com>,
   "ML CygWIN" <cygwin AT cygwin DOT com>
X-OriginalArrivalTime: 24 Oct 2003 14:41:56.0685 (UTC) FILETIME=[F93E97D0:01C39A3C]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id h9OEgC6E026740

> Hmm? Is waitpid() a blocking call or not? WRT "WNOHANG" it 
> looks like an
> unblocking one...

Yep.
 
>  Thus I'm assuming it doesn't block and that msleep() is 
> something internal
> to rsync, using usleep() or some such.

It uses select(). When I used strace on a non-modified version of rsync
to watch where it hung, here's the last bit of output I saw:

   18 9449430 [main] rsync 3260 stopped_or_terminated: considering pid
3276
   18 9449448 [main] rsync 3260 checkstate: returning -1
   18 9449466 [main] rsync 3260 proc_subproc: waiting thread found no
children
   20 9449486 [main] rsync 3260 proc_subproc: finished processing
terminated/stopped child
   18 9449504 [main] rsync 3260 proc_subproc: returning 1
   21 9449525 [main] rsync 3260 wait4: 0 = WaitForSingleObject (...)
   19 9449544 [main] rsync 3260 wait4: intpid 3276, status 0x22FE28,
w->status 0, options 1, res 0
   20 9449564 [main] rsync 3260 cygwin_select: 0, 0x0, 0x0, 0x0,
0x22FDC0
   19 9449583 [main] rsync 3260 cygwin_select: to->tv_sec 0, to->tv_usec
20000, ms 20
   18 9449601 [main] rsync 3260 cygwin_select: sel.always_ready 0

It never got past cygwin_select().

> of the patch is
> called "busy waiting" and is a *hard* blow against all other 
> software that
> is running at the same time.

But, it's OK for me because a) It fixes the problem b) It doesn't wait
long at all c) It doesn't appear to tie up resources.

> If the loop exit condition appears "late" the machine 
> running the above
> code will experience jerkyness and other ill effects - at the 
> extreme but
> still likely level there might even be disturbances of *vital* system
> functions (e.g. related to time critical tasks).

Nope, I haven't seen any of this. It could happen, I'm sure.

> The bottom point: *don't do that* ;-)
>  i.e. leave the msleep() call there.

If I leave msleep there, it hangs every time. So I'm taking it out. Now,
this fixes one hang at one time, but not others. For instance, if there
is nothing to do since the sources and targets are in sync, it'll hang.
If the source dir doesn't exist, it still hangs. I'm now going to see if
I can isolate the heart of the problem with a simple program that forks
and sleeps in the same fashion as with rsync.

Luke

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/