Re: Waiting for callback with GCD: impossible?
Re: Waiting for callback with GCD: impossible?
- Subject: Re: Waiting for callback with GCD: impossible?
- From: Ken Thomases <email@hidden>
- Date: Wed, 08 Oct 2014 15:52:50 -0500
On Oct 8, 2014, at 3:15 PM, Jens Alfke <email@hidden> wrote:
> On Oct 8, 2014, at 12:28 PM, Ken Thomases <email@hidden> wrote:
>>
>> Queues are not like run loops nor threads. Your desire to have ongoing logic occur on a particular queue seems odd to me.
>
> I don't think it's odd to want an ongoing single flow of control for specific parts of the program. Limiting parallelism makes it a lot easier to reason about the code's behavior.
We're not talking about parallelism here, at least not any more so than you already had by having A and B. We're talking about (a)synchronicity, which is a separate thing.
For example, this is still serial execution (of this local logic) and a "single flow of control":
mainThreadTask1();
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
backgroundTask1();
dispatch_async(dispatch_get_main_queue(), ^{
mainThreadTask2();
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
backgroundTask2();
dispatch_async(dispatch_get_main_queue(), ^{
mainThreadTask3();
// etc.
});
});
});
});
> You can create one of those with a background thread, but my understanding is that we're encouraged to use serial dispatch queues instead.
I don't know where you got that impression, but that seems like a terrible idea to me. First of all, a queue is just a data structure. A queue doesn't run anything, itself. It is still serviced by threads. If you're not using the data management features of the queue — its width, suspending/resuming, barrier tasks, etc. — there's little point.
Submitting long-running tasks to a global concurrent queue is a perfectly acceptable way to get them to run on a background thread. Some people object, but I have no problem with it. It doesn't have any particular advantage over spawning a thread, though.
But using a custom queue for that, just to avoid creating a thread explicitly, seems pointless to me. And I especially don't see the point in using a serial queue when you don't need to synchronize.
>> The main purpose for custom queues would be to synchronize access to specific resources. Why is there "logic on queue A" that's doing anything other than briefly accessing a shared resource?
>
> I disagree about that, actually. The advice to wrap critical sections in dispatch_async calls turns out to produce a _lot_ of overhead. I briefly used it in some performance-sensitive code this spring, but had to rip it out because a large fraction of runtime was being spent in OS code that scheduled dispatch queues, copied/freed blocks, juggled retain counts, etc. It was a lot faster to just use @synchronized, and faster still to make the classes in question single-threaded and push the synchronization tasks up to a higher level of the code. (This isn't just obsessing over clock cycles; I'm literally talking about 2x performance improvements in high-level benchmarks.)
That doesn't seem like a disagreement to me. I said that's the purpose for custom queues. You say they aren't well suited for the purpose. That doesn't change the fact that that's their purpose. If you find them poorly suited, then that's all the stronger argument not to use them.
Regards,
Ken
_______________________________________________
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