• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: readInBackgroundAndNotify and rsync output
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: readInBackgroundAndNotify and rsync output


  • Subject: Re: readInBackgroundAndNotify and rsync output
  • From: Ken Thomases <email@hidden>
  • Date: Sat, 29 Jan 2011 04:15:57 -0600

On Jan 29, 2011, at 2:16 AM, Robert DuToit wrote:

> Thanks Ken,

You're welcome.

> Your thoughtful answer clarified what I have been experiencing.

I'm glad I could help.

> On recent machines readInBackground is definitely a small toll compared to rsync - it is on older slower Macs that the toll got closer to rsync's write and really crunched it.

First, it shouldn't be the readInBackground, per se, that accounts for any significant overhead.  It's presumably the parsing you're doing.

Second, I would think that the performance of rsync would scale at roughly the same rate as your parsing code.  So, I would expect it to be able to keep up just as well on older system as newer ones. *shrug*


> My app for years had been using an external log for rsync to write to and a timer for polling and it does work nicely, though with rsync the file can get enormous now with TB's of data transfer

I would think it would be the number of files, not the total data size, that would be relevant.

> and there is overhead with streaming calls to NSTask 'tail' and 'ps' to see if rsync is still running.

You should definitely not be creating subprocesses to run 'tail' or 'ps'.  'tail' is just a file reader, and your app can directly open and read the file.  To monitor whether rsync is still running, you may be able to use the techniques illustrated in these articles:

http://developer.apple.com/library/mac/#technotes/tn/tn2050.html
http://developer.apple.com/library/mac/#qa/qa2001/qa1123.html

If you adapt the latter, you don't have to read in and scan the whole process list each time.  The sysctl(3) man page shows alternative third-level names to use instead of KERN_PROC_ALL, including KERN_PROC_PID which lets you query a single known PID.

It may also be possible to use a pipe to the rsync process not for communicating its output but just to monitor its lifetime.  If you redirect most of rsync's output to a file (e.g. using the --log-file option), then you can monitor its stdout (and/or stderr) from your app.  When it closes, the process has presumably exited.

Cheers,
Ken

_______________________________________________

Cocoa-dev mailing list (email@hidden)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:

This email sent to email@hidden

  • Follow-Ups:
    • Re: readInBackgroundAndNotify and rsync output
      • From: Robert DuToit <email@hidden>
References: 
 >readInBackgroundAndNotify and rsync output (From: Robert DuToit <email@hidden>)
 >Re: readInBackgroundAndNotify and rsync output (From: Ken Thomases <email@hidden>)
 >Re: readInBackgroundAndNotify and rsync output (From: Robert DuToit <email@hidden>)

  • Prev by Date: Re: readInBackgroundAndNotify and rsync output
  • Next by Date: Re: readInBackgroundAndNotify and rsync output
  • Previous by thread: Re: readInBackgroundAndNotify and rsync output
  • Next by thread: Re: readInBackgroundAndNotify and rsync output
  • Index(es):
    • Date
    • Thread