On Oct 3, 2013, at 11:09 AM, Daniel DeCovnick <[email protected]> wrote:
> You did not miss anything. Since a queue can run on any or multiple threads > (except the main queue), creating a runloop on it - and runloops are > thread-specific - means that one dispatched block may run on a thread that > doesn’t have the runloop created in another by a previously dispatched block. It’s that “except the main queue” thing I want to get around. I want a dispatch queue that behaves like the main queue, but for a different thread. Why should the main thread/queue be magic in this regard? > What are you trying to do? There’s an impedance mismatch between code that does scheduling using threads/runloops, and code that does it using dispatch queues. The two styles don’t interoperate, _unless_ the code runs only on the main thread. I end up tripping over this when I write code that does asynchronous processing. For example, if I’ve implemented a class (or borrow someone else’s open-source class) that reads from an NSStream, it’ll be scheduling the stream with the current runloop. That makes it unusable with dispatch queues. (You can see the effect of this in a number of APIs — for example, NSURLConnection can have its callbacks scheduled either onto a runloop or onto a dispatch queue, which is messy. And worse, it means that code that uses NSURLConnection has to know whether it’s being invoked from an NSThread or a dispatch queue, so that it can make the correct scheduling call. And that means the code that calls _that_ code has to know, all the way up the chain. It ends up turning into a big refactoring.) I’m working on a large codebase that doesn’t use dispatch queues, but creates background NSThreads to do its work. It would be nice to migrate it to GCD, but there doesn’t seem to be a way to do so without ripping out every vestige of thread/runloop dependent code (all the delayed-perform calls, NSTimers, NSThread creation, scheduleWithRunloop calls…) and replacing them en masse with GCD equivalents. I’m loath to do that with mature and complex code, especially because concurrency bugs are so hard to fix. I would much rather be able to incrementally switch. —Jens _______________________________________________ Cocoa-dev mailing list ([email protected]) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [email protected]
