Thanks, Graham. I don't want to use NSFileManager because (AFAICT)
you can't ask it how far along it's gotten. Also I don't see a way to
cancel a copy in the middle.
I'm not familiar with these ops, but having browsed the docs just
now, it seems to me what's happening is that because you've
scheduled the operation with your main run loop, it's not really
"asynchronous" as much as time-sharing with your main loop, which is
why your UI is jumpy.
Sure, it seems like it's just another dispatch from the runloop.
Which would be fine if it copied like 100K bytes per invocation, or
something like that. It seems instead to run off and copy vast
quantities of data before returning. Copying a 4MB MP3 file actually
completes before the first time anything else in the runloop gets any
service. I was hoping I had just missed how to adjust the time slices
it takes.
I'll go ahead and spawn a new thread, install a runloop, and use
FSCopyObjectAsync over there. That's what I was planning to do
anyway, but whilst reading about runloops and threads I kept being
told to use the built-in async functions because they're more
efficient and easier to use and harder to mess up. Seems like maybe
with this one, not so much.
Thanks,
Kevin
On Jun 9, 2010, at 2:46 AM, Graham Cox wrote:
On 09/06/2010, at 4:43 PM, Graham Cox wrote:
You could try setting up a runloop on another thread to get truly
asynchronous copying, and then ensure that the progress update is
performed on the main thread as needed.
Or maybe use NSFileManager to perform the copy which is higher-level
and thread-safe.
--Graham
_______________________________________________
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
