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 (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
