Re: External kill of an NSThread?
Re: External kill of an NSThread?
- Subject: Re: External kill of an NSThread?
- From: Roland Torres <email@hidden>
- Date: Tue, 21 Nov 2006 19:38:47 -0800
On Nov 21, 2006, at 6:46 PM, John Stiles wrote:
On Nov 21, 2006, at 6:43 PM, Murat Konar wrote:
On Nov 21, 2006, at 6:19 PM, Roland Torres wrote:
On Nov 21, 2006, at 5:29 PM, Murat Konar wrote:
On Nov 21, 2006, at 3:46 PM, Roland Torres wrote:
Depends on what is wrong. There are many ways a URL can be
"invalid". It might not conform to the URL spec, the host
specified in the URL might not exist or be reachable, the
resource pointed to by the URL might not exist, etc.
By "invalid" I just mean that the URL doesn't exist or is
inaccessible. If I could validate the URL before calling the
3rd party library, then I would be able to avoid the whole
thing hanging. Sadly, Cocoa objects that use -
initWithContentsOfURL: just hang forever on URLs they can't
access,
Are you sure? I just tried [NSData dataWithContentsOfURL:url],
and I couldn't get it to hang. Feeding it a URL to a non-
existent host just results in an NSData object with zero length.
Here's my test app. <http://muratnkonar.com/source-code/
URLTest.zip>
Interesting. You're quite right for invalid URLs, it returns
immediately. But try entering an inaccessible URL like "http://
192.168.0.20" in your little app. It hangs on this for me for
about 1min 15secs, but it does come back eventually. This might
be salvagable if there's a way to shorten the wait time.
Well, it's not "hung", it's just giving the other end ample time
to respond. Safari and Firefox behave the same way.
Getting data from a URL with adjustable timeout is outlined at
<http://developer.apple.com/documentation/Cocoa/Conceptual/
URLLoadingSystem/Tasks/UsingNSURLConnection.html>
This means that you'll have to download the data yourself and feed
it to your 3rd party lib, (if possible). Alternatively, you could
use this technique to preflight your call to your 3rd party lib.
Just try to download some small bit of data to verify that the
other end is alive and ready to play, then call your library.
If he's already willing to spin off a thread to do the work, all he
needs to do is wait for the thread to complete.
Why kill the thread early? Just let it take however long it needs,
and if the user gets tired of waiting, let them cancel and then
sweep up after the thread whenever dataWithContentsOfURL:url returns.
Yes, this makes a lot of sense, especially since it *is* going to
timeout eventually. I'll just "abandon" the thread (from the user
point of view). When it does complete, I call MPExit() from within
the thread, and it's all good.
Thanks for your help, guys, I learned a lot!
Roland
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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