Is calling -[NSRunLoop runUntilDate:] a good idea?

Question

Is it generally a good idea to call -[NSRunLoop runUntilDate:]? It seems to work without any issues, but it makes me nervous to tell the run loop to run from within the run loop.

More info:

I have a project right now that is fetching data from a REST service. One critical piece of information that needs to be obtained is the range of dates with valid data. It's a very small bit of data that only needs to be gotten once, so I decided that the best way to handle it is to have the property download the data if the local variable is nil. I'm using ASIHTTPRequest and an ASINetworkQueue, so everything is asynchronous by default, and in order for this to work, this property can't return until the data has been downloaded and processed. Here's an outline of my code, the names of variables have been changed to protect the innocent:

__block BOOL isWorking = YES;
__block ASIHTTPRequest *request = [[[ASIHTTPRequest alloc] initWithURL:/*actual URL*/] autorelease];
[request setCompletionBlock:^{
    // set local variable
    isWorking = NO;
}];
[request setFailedBlock:^{
    // show alert to user
    isWorking = NO;
}];
[queue addOperation:request];

while (isWorking) {
    [[NSRunLoop currentRunLoop] runUntilDate:[NSDate dateWithTimeIntervalSinceNow:0.1]];
}

Again, this seems to be working fine. Are there any potential issues with using this approach?

Answer 1

You have to make sure not to do this from any method that could be called by the run loop you are invoking, unless the overlapping call tree is completely re-entrant.

The Cocoa Touch UI code is not documented as re-entrant (in fact, there are warnings/hints from Apple DTS that it is not), so if your fetch data handler can in any way be called by a UI method (or other non-reentrant code that could be called in the UI run loop), calling the UI run loop from inside it is not recommended.

Answer 2

Isn’t it better to display some kind of a spinner and tear it down in response to the async completion events from the networking code? Like:

[self displayLoadingSpinner];
[request setCompletionBlock:^{
    [self handleSuccess];
    dispatch_async(dispatch_get_main_queue(), ^{
        [self hideLoadingSpinner];
    }];
}];
[request setFailedBlock:^{
    [self handleFailure];
    dispatch_async(dispatch_get_main_queue(), ^{
        [self hideLoadingSpinner];
    }];
}];
[queue addOperation:request];

I would consider this better than monkeying with the run loop. But it could be that you already know this and just want to know what exact drawbacks are there in the runloop solution?

---

If you want to block until the value is ready, you can use a semaphore:

dispatch_semaphore_t sem = dispatch_semaphore_create(0);
[request setCompletionBlock:^{
    dispatch_semaphore_signal(sem);
}];
[queue addOperation:request];

dispatch_semaphore_wait(sem, DISPATCH_TIME_FOREVER);
dispatch_release(sem);