Re: Can I create a thread with a runloop and a dispatch queue?
Re: Can I create a thread with a runloop and a dispatch queue?
- Subject: Re: Can I create a thread with a runloop and a dispatch queue?
- From: Mike Abdullah <email@hidden>
- Date: Thu, 03 Oct 2013 22:09:32 +0100
On 3 Oct 2013, at 20:00, Jens Alfke <email@hidden> wrote:
>
> On Oct 3, 2013, at 11:46 AM, Kyle Sluder <email@hidden> wrote:
>
>> There is magic sauce in CFRunLoop that runs the main queue as part of
>> processing the runloop. All other queues are managed by code running on
>> a thread managed by libdispatch. The main queue is a special case; it
>> doesn't make sense for this relationship to exist for other queues.
>
> Why doesn’t it make sense?
>
> A runloop is conceptually very much like a serial dispatch queue. Both are mechanisms for handling incoming requests/calls/events in order. Why are the two divorced, except for the special case of the main thread?
>
> I think this would fix some current problems. For example, dispatch_get_current_queue is deprecated, and the only reason I can think of is that it may return NULL if the caller isn’t running under the control of a dispatch queue. If threads with runloops had dispatch queues, then dispatch_get_current_queue would work correctly in this very common case, making it more reliable.
The real reason it's deprecated is because there isn't truly such a thing as the current queue. Any custom queues you create must have a target queue that actually performs their work.
So for example, if you create a serial queue, by default it targets DISPATCH_QUEUE_PRIORITY_DEFAULT (the default "global concurrent queue"). So any work submitted to your serial queue, when it's executed, there are actually *two* active queues at the time. Your serial one, and the global one.
You can actually target a custom queue at any other queue you like, to create a whole chain of them. Work submitted to such queues ends up executing within the context of multiple queues at once.
Apple introduced dispatch_get_specific() to handle some of this. It looks up the stack of all queues executing a block to find the first one referencing a given key. The important bit being it admits there are potentially multiple "current" queues.
The other good reason for doing away with dispatch_get_current_queue is it makes it easy to accidentally leak out private queues for other code to capture and abuse.
Ultimately, Apple are moving towards APIs (at least at the higher level) where clients explicitly specify the operation queue they'd like callbacks to be executed on. I think it would be wise to adopt that too.
_______________________________________________
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