Re: Stop NSFileManager copyFile in progress? Can you kill a thread?
Re: Stop NSFileManager copyFile in progress? Can you kill a thread?
- Subject: Re: Stop NSFileManager copyFile in progress? Can you kill a thread?
- From: "Michael Ash" <email@hidden>
- Date: Tue, 11 Nov 2008 00:27:52 -0500
On Mon, Nov 10, 2008 at 4:45 PM, David <email@hidden> 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 (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