On a related topic from my last post, looking at the equivalent situation but
using GCD instead of runloops, the problem appears to be impossible. That is:
* Code running on dispatch queue A starts some async task that will run on
another queue B, and which will signal completion by using
* 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.
You could use some other signaling
On Oct 8, 2014, at 11:59 AM, Jens Alfke j...@mooseyard.com wrote:
* 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
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
On Oct 8, 2014, at 12:06 PM, davekeck . davek...@gmail.com wrote:
You could use some other signaling mechanism -- a dispatch_semaphore_t
or NSConditionLock, for example.
Yeah, but that doesn't work for the async mode, where I need a dispatch_async
call to queue A to notify it.
Maybe I'd
On Oct 8, 2014, at 12:28 PM, Ken Thomases k...@codeweavers.com 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
On Oct 8, 2014, at 3:15 PM, Jens Alfke j...@mooseyard.com wrote:
On Oct 8, 2014, at 12:28 PM, Ken Thomases k...@codeweavers.com 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
