On Oct 8, 2014, at 1:59 PM, Jens Alfke <j...@mooseyard.com> wrote: > * Code running on dispatch queue A starts some async task that will run on > another queue B, and which will signal completion by using dispatch_async to > call a completion block on queue A, passing it some result. > > * After the task starts, the logic on queue A decides it needs to block until > the task finishes and returns its result. (This might be part of an > implementation of the 'future' design pattern, for example.)
Queues are not like run loops nor threads. Your desire to have ongoing logic occur on a particular queue seems odd to me. 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? For what it's worth, GCD isn't a good fit for the "future" design pattern. The GCD "way" of doing this is to have a task that will be executed asynchronously at the time the result becomes available. The A logic shouldn't wait; it should arrange for whatever work it would do when the wait is over to happen at that time. Then it should end. > * Now, how does queue A wait for the callback? It seems to be impossible: the > only way for code running on queue A to receive the callback is to return > back to the queue dispatcher, so if it tries to wait it simply blocks the > queue, causing a deadlock. Yup. > But given that dispatch queues can't do this, what's the solution to this > design problem, i.e. turning an async call into a sync one? Avoid it. The desire to turn async work to synchronous work is the root of the problem. That said, the task on queue B could signal a semaphore or leave a group, rather than attempting to submit a task to queue A. If you must block waiting for the result, the A logic could wait on the semaphore or group. Better would be to use dispatch_group_notify() to just perform the when-the-result-is-ready work when it's ready. 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
