On Oct 3, 2013, at 1:23 PM, Ken Thomases <[email protected]> wrote:
> I've seen APIs, including some from Apple, that take a queue as an argument > for where a completion block should be invoked. I've always thought they > were a bit silly. If the caller's onComplete block needs to be run in a > particular context, let them wrap it in a dispatch_async() to shunt it over > to that context. Interesting point. But it would complicate the caller’s job, and I can foresee some developers forgetting (or not knowing) to do this and then coming to me with weird and sporadic concurrency bugs. (I already get enough RTFM questions in the support forum…) My bias is generally to complicate the implementation’s code, rather than make all the callers complicate their code, because that saves effort globally. But you’re right that it would make it more flexible. Anyway, thanks for giving the first constructive answer :) > I'm not seeing how the above API would be easier/cleaner to implement if run > loops had queues. Because the implementation could initially capture the current dispatch queue (by calling dispatch_get_current_queue) and then when the block is ready to be called, invoke it via dispatch_async on that captured queue. Currently this works only if the method was called from a dispatch queue, but will break if called otherwise, i.e. from normal runloop-based code, because dispatch_get_current_queue will return NULL. —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]
