On Mon, Nov 10, 2008 at 4:45 PM, David <[EMAIL PROTECTED]> wrote: > I have NSFIleManager copying files in a secondary thread. The user can > select to cancel the copy. > Is there a way to force NSFileManager to stop copying a file? The > files could be of arbitrary size. A large file could take quite a > while to end. I currently check if the thread has been cancelled > between files, but I can't figure out how to stop it if its in the > middle of copying one file. > > Is there a way to make NSFileManager stop a copy operation? > Is there a way to forcibly kill a thread and thereby stop NSFileManager?
Just for the sake of completeness, you can kill an individual thread by using the pthread_cancel function. This is "just for the sake of completeness" because the use of thread cancellation places extreme restrictions on the activities of the target thread, and as such it's nearly useless in practice. There are actually two types of cancellation, but neither of them really work for what you want: - Asynchronous cancellation kills the target thread essentially at any time. This makes it extremely difficult to write safe code in the target thread, because it needs to die safely no matter when it dies, even in between two lines of code in the same function, even in between two instructions generated from a single line of code. - Deferred cancellation kills the target thread the next time it hits a "cancellation point", which is one of a small set of library functions. (The full list can be found in the man page for pthread_testcancel.) The fact that cancellation can only happen at these defined points helps with writing a cancel-safe thread, since you just have to ensure that things are in a good state to either disappear or be cleaned up just before calling any of those functions. The reason neither one helps you is because it's not your code that you're worrying about, it's NSFileManager. Unless a library makes explicit guarantees about its safety regarding thread cancellation, you can't assume that it's safe. At the very least, you are virtually guaranteed to leak memory if you cancel a thread that is in the middle of executing NSFileManager code. You could also end up with corrupt memory, with locks being held that never get freed, and with a number of other problems that can hang or crash your app in rapid fashion. You can cancel the thread safely by writing your own code to be cancel safe, then disabling cancellation before you enter any Cocoa code, and re-enabling it afterwards. But of course this brings you right back to the original problem, which is that NSFileManager can take arbitrarily long to finish its job and return you to a point where your thread can be cancelled. At this point you've gained nothing over an explicit cancellation check. It's really too bad that it doesn't work, because it could be a useful technique in scenarios like this, but so it goes. Mike _______________________________________________ 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 [EMAIL PROTECTED]
