This is the mail archive of the mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: rsync local dir copy hang - solved for me

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

>  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
   18 9449448 [main] rsync 3260 checkstate: returning -1
   18 9449466 [main] rsync 3260 proc_subproc: waiting thread found no
   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,
   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.


Unsubscribe info:
Problem reports:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]