Re: External kill of an NSThread?
Re: External kill of an NSThread?
- Subject: Re: External kill of an NSThread?
- From: Chris Suter <email@hidden>
- Date: Wed, 22 Nov 2006 14:45:44 +1100
On 22/11/2006, at 2:38 PM, Roland Torres wrote:
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
Be a little bit careful with leaving the thread running. Check that
there isn't an issue if the user cancels and then you start another
thread up so that there are two threads running. Make sure you get
expected behaviour when he first one terminates before the second one
has finished.
I haven't followed this topic from the beginning so forgive me if
this doesn't seem applicable.
- Chris
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
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