On Oct 3, 2013, at 3:00 PM, Jens Alfke wrote: > Also, my project is a library, and I don’t want to put too many restrictions > on how it’s used by the caller. For example, here’s one method that runs an > async query: > - (void) runAsync: (void (^)(CBLQueryEnumerator*))onComplete; > When the query results are available, the onComplete block is called. The > problem is, in what context should the block be called? Currently it’s > scheduled on the same runloop as the original call. That works great for > runloop-based clients. But if this method is called from a dispatch queue > (except the main one) it won’t work. Do I have to have a second variant, like > runAsync:onQueue:, that does the same thing except it invokes the block on a > queue?
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. Or, if they prefer to use run loops and explicit threads, let them use the previously-hypothesized -[NSThread performBlockAsync:] to shunt it. The API should invoke it on an arbitrary context (whatever is easiest for the implementation) rather than making guarantees that may not be needed, useful, or appropriate for the needs of the caller. Only the caller knows its needs, so let/make it control that. > That’s messy, and if runloops had queues it would be unnecessary. I'm not seeing how the above API would be easier/cleaner to implement if run loops had queues. Regards, Ken _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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 arch...@mail-archive.com
