How to call a method a.s.a.p. but at earliest in t

Question

I need a save way to say: "iOS, I want this method to be executed a.s.a.p., but NOT in THIS run loop iteration. At the earliest in the next, but please not in this one. Thank you."

Right now I am always doing it like this:

[self performSelector:@selector(doSomethingInNextRunLoop) withObject:nil afterDelay:0];
[self doSomeOtherThings];

With the assumption that -doSomeOtherThings will always be performed BEFORE -doSomethingInNextRunLoop.

The documentation says:

Specifying a delay of 0 does not necessarily cause the selector to be performed immediately. The selector is still queued on the thread’s run loop and performed as soon as possible.

So basically it can happen that the method gets called immediately as if I had just sent a direct message, causing -doSomethingInNextRunLoop to be executed before -doSomeOtherThings?

How can I make absolutely sure it will be called a.s.a.p. but NEVER ever in this same run loop iteration?

To clarify the wording: With run loop I mean the main thread, and the iteration in which all methods must return until the thread is ready again for new events.

Answer 1

Surely you just do this;

[self doSomeOtherThings];
[self performSelector:@selector(doSomethingInNextRunLoop) withObject:nil afterDelay:0];

Which guarantees the execution order you want.

Answer 2

Quite trivial using GCD (Grand Central Dispatch):

dispatch_async (dispatch_get_main_queue (), ^{
    NSLog (@"This stuff runs in the next iteration of the main run loop");
});

Answer 3

I think you conclusion from reading the documentation is wrong.

So basically it can happen that the method gets called immediately as if I had just sent a direct message

No. The part of the documentation you quote says that the selector is always queued on the run loop, no matter what. So it will never be executed just as a direct message.

The first sentence with the "not necessarily" might be a bit misleading, but I think the second sentence should really clarify that what you fear is not gong to happen.

Answer 4

If you're worried that Apple may someday special-case a delay of 0, you could always specify a delay of 1e-37 or so. Although the documentation for performSelector:withObject:afterDelay: could easily be read to guarantee that the selector will always be scheduled for the next run loop iteration.

If you're worried that Apple may someday special-case delays less than some arbitrary lower bound, you could always try using NSRunLoop's performSelector:target:argument:order:modes: which the documentation specifically states will schedule execution for the next iteration of the run loop.