CODEWITHSUNDEEP
iosobjective-cios6grand-central-dispatch
Boon
Boon

Reputation: 41510

How to dispatch_after in the current queue?

Now that dispatch_get_current_queue is deprecated in iOS 6, how do I use dispatch_after to execute something in the current queue?

Upvotes: 8

Views: 3835

Answers (3)

Rob Napier
Rob Napier

Reputation: 299623

The various links in the comments don't say "it's better not to do it." They say you can't do it. You must either pass the queue you want or dispatch to a known queue. Dispatch queues don't have the concept of "current." Blocks often feed from one queue to another (called "targeting"). By the time you're actually running, the "current" queue is not really meaningful, and relying on it can (and historically did) lead to dead-lock. dispatch_get_current_queue() was never meant for dispatching; it was a debugging method. That's why it was removed (since people treated it as if it meant something meaningful).

If you need that kind of higher-level book-keeping, use an NSOperationQueue which tracks its original queue (and has a simpler queuing model that makes "original queue" much more meaningful).

There are several approaches used in UIKit that are appropriate:

  • Pass the call-back dispatch_queue as a parameter (this is probably the most common approach in new APIs). See [NSURLConnection setDelegateQueue:] or addObserverForName:object:queue:usingBlock: for examples. Notice that NSURLConnection expects an NSOperationQueue, not a dispatch_queue. Higher-level APIs and all that.
  • Call back on whatever queue you're on and leave it up to the receiver to deal with it. This is how callbacks have traditionally worked.
  • Demand that there be a runloop on the calling thread, and schedule your callbacks on the calling runloop. This is how NSURLConnection historically worked before queues.
  • Always make your callbacks on one of the well-known queues (particularly the main queue) unless told otherwise. I don't know of anywhere that this is done in UIKit, but I've seen it commonly in app code, and is a very easy approach most of the time.

Upvotes: 5

CouchDeveloper
CouchDeveloper

Reputation: 19164

Having to do this is likely because the need of a hack. You can hack around this with another hack:

id block = ^foo() {
    [self doSomething];
    usleep(delay_in_us);  
    [self doSomehingOther];
}

Instead of usleep() you might consider to loop in a run loop.

I would not recommend this "approach" though. The better way is to have some method which takes a queue as parameter and a block as parameter, where the block is then executed on the specified queue.

And, by the way, there are ways during a block executes to check whether it runs on a particular queue - respectively on any of its parent queue, provided you have a reference to that queue beforehand: use functions dispatch_queue_set_specific, and dispatch_get_specific.

Upvotes: 0

Jurre
Jurre

Reputation: 129

Create a queue manually and dispatch both your calling code and your dispatch_after code onto that. That way you can guarantee that both pieces of code are run from the same queue.

Upvotes: 1

Related Questions