Async NSURLConnection + Concurrent NSOperation = Not possible under Mac OS X 10.6?
Async NSURLConnection + Concurrent NSOperation = Not possible under Mac OS X 10.6?
- Subject: Async NSURLConnection + Concurrent NSOperation = Not possible under Mac OS X 10.6?
- From: Steven Degutis <email@hidden>
- Date: Sun, 30 Aug 2009 09:09:58 -0500
Hi all,
I've been writing a class that will be the new primary class for my
CocoaREST library, and the class is basically an NSOperation that fetches
data over HTTP protocol and parses it for the user.
When writing this subclass of NSOperation about a week or two ago, it was
using NSURLConnection in an async fashion, much like Dave Dribin talks about
over here in his blog post at
http://www.dribin.org/dave/blog/archives/2009/05/05/concurrent_operations/
Unfortunately, the code I wrote completely broke yesterday when I upgraded
to Snow Leopard (fortunately I hadn't published it yet for that same reason)
and it was narrowed down to the NSOperation subclass not getting any of
NSURLConnection's delegate methods at all. In fact, it seemed that the
object wasn't even getting any messages from
-performSelector:withObject:afterDelay: either, which made me wonder whether
the NSRunLoop of the current NSThread was borked, or if the NSThread itself
was in fact not intact.
Interestingly, it still worked fine when the NSOperation object was run with
-start, it only failed when run by being added to an NSOperationQueue.
So after more researching of NSOperationQueue's documentation, specifically
under "Avoid Per-Thread Storage" section of the "Operation Queues" guide, it
states the following:
"If an operation queue provides a thread for you, you should consider that
thread to be owned by the queue and not to be touched by your operation.
Specifically, you should never associate any data with a thread that you do
not create yourself or manage. The threads managed by an operation queue
come and go depending on the needs of the system and your application.
Therefore, passing data between operations using per-thread storage is
unreliable and likely to fail."
It seems to be that this exactly describes what is happening when
NSURLConnection is run asynchronously; it tries to use the thread it's
current in and its runloop, even though it created neither, since
NSOperationQueue did.
First of all, am I reading and interpreting this correctly? I could be
mistaken on what this means, as I'm no expert to threads and runloops.
Secondly, if so, would it be unwise to set up a thread and runloop
specifically for the NSURLConnection itself? The primary benefit
NSURLConnection would get from running async inside an NSOperation subclass
is that it will be more easily cancelable, but that's definitely not more
important than the whole class working altogether with GCD, so it could be
dropped in the blink of an eye if this isn't a feasible idea.
Thanks in advance.
--
Steven Degutis
http://www.thoughtfultree.com/
http://www.degutis.org/
_______________________________________________
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