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 (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 arch...@mail-archive.com
