• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: How do I use NSStream with dispatch queues?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: How do I use NSStream with dispatch queues?


  • Subject: Re: How do I use NSStream with dispatch queues?
  • From: Jens Alfke <email@hidden>
  • Date: Tue, 20 Mar 2012 22:44:00 -0700


On Mar 20, 2012, at 7:25 PM, Steve Sisak wrote:

Are you sure that this is the right tool for the job? If the API you're working from is runLoop based, what does this buy you (besides a warm feeling of being "modern")?

I don't want to hijack the internal NSURLConnection thread for my own purposes (not all of which directly involve handling URL requests). More details on that below.

This is as simple as [self detachNewThreadWithSelector:] and in your selector method caching the current thread and runLoop in instance variables, then enter a runloop (preferably with at least one source so it doesn't exit immediately).
Then, when ever you want to do something in a synchronized manner, call performSelector:onThread:withObject:waitUntilDone: using your utility thread.

As I said, I've done it before (the RSS reading agent in 10.4 ran its SQLite calls on a background thread) and I found it annoying to implement and subject to bugs. There are lots of little gotchas like, when starting the thread you don't actually have any NSThread* reference until it's had time to call into the selector you're performing, so there's some synchronization involved in simply getting the NSThread instance to call later.

I don't want to do things the new way just to be "modern". I want to because it's best to go with the grain of the frameworks, and GCD seems to be the way that multiprocessing is meant to be done these days. I was just surprised to find out that, even three years later, it's still pretty incomplete.

Also, since NSURLProtocol is a glorified delegate to the URL loading system, I'm not sure that running on its threads poses any problem -- am I missing something?

It's an internal thread managed by CFNetwork that all Apple's URL-loading code runs on. So if my code blocks too long in that thread I can clog up other network activity. And I have no guarantee that this will continue to be a single thread in the future (maybe it turns into a pool), so my code's synchronization might get messed up as a result. And initially I was worried whether terrible things would happen if I *initiated* NSURLConnections from that thread, although that did seem to work fine. I could go on.

—Jens

 _______________________________________________
Do not post admin requests to the list. They will be ignored.
Macnetworkprog mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:

This email sent to email@hidden

References: 
 >How do I use NSStream with dispatch queues? (From: Jens Alfke <email@hidden>)
 >Re: How do I use NSStream with dispatch queues? (From: Raffi Khatchadourian <email@hidden>)
 >Re: How do I use NSStream with dispatch queues? (From: Mark Pauley <email@hidden>)
 >Re: How do I use NSStream with dispatch queues? (From: Raffi Khatchadourian <email@hidden>)
 >Re: How do I use NSStream with dispatch queues? (From: Jens Alfke <email@hidden>)
 >Re: How do I use NSStream with dispatch queues? (From: Steve Sisak <email@hidden>)

  • Prev by Date: Re: How do I use NSStream with dispatch queues?
  • Next by Date: iOS deadlocks calling queue-based URL connection delegate
  • Previous by thread: Re: How do I use NSStream with dispatch queues?
  • Next by thread: Re: How do I use NSStream with dispatch queues?
  • Index(es):
    • Date
    • Thread