NSRunLoop freezes app on iPad Pro under iOS10 - objective-c

Question

I got a synchronous request inside a custom operation that looks like this:
NSURLSessionConfiguration *sessionConfig = [NSURLSessionConfiguration defaultSessionConfiguration];
NSURLSession* session = [NSURLSession sessionWithConfiguration:sessionConfig delegate:self delegateQueue:nil];
NSURLSessionDataTask* task = [session dataTaskWithRequest:request completionHandler:^(NSData *_data, NSURLResponse *_response, NSError *_error)
{
self->data = [_data retain];
self->tempResponse = _response;
self->tempError = [_error retain];
self->done = true;
}];
[task resume];
// wait until the connection has finished downloading the data or the operation gets cancelled
while (!self->done && !self.isCancelled)
{
[[NSRunLoop currentRunLoop] run];
}
This code is pretty old but has worked through several iOS versions (only replaced NSURLConnection at some point). Now under iOS 10 on the iPad Pro this code will freeze my app. If I put the app into the background and reopen it, it will run again. Also if I put breakpoints on [task resume] and self->data = [_data retain]; no freeze will happen at all.
I found one way to fix it inside the code, by adding an NSLog to the run loop:
while (!self->done && !self.isCancelled)
{
NSLog(#"BLAH!");
[[NSRunLoop currentRunLoop] run];
}
This eats quite some performance and won't help in the long run since all NSLogs are removed for the release configuration.
So I need a way to fix this bug. Maybe the code is too old and there's a new way to do it, I have no idea. Any help is appreciated.

Answer 1

The -run method will go forever until all timers etc. are removed from the run loop. The documentation states:
Manually removing all known input sources and timers from the run loop
is not a guarantee that the run loop will exit. macOS can install and
remove additional input sources as needed to process requests targeted
at the receiver’s thread. Those sources could therefore prevent the
run loop from exiting.
So, it's possible that iOS 10 is adding another input source which is only removed when the device is backgrounded, or something like that. Or, the -run method was perhaps always returning immediately before, if there were no timers or sources (but that would be a busy wait using lots of CPU). You really don't have much control using that method, and possibly some of the others.
I have used the following NSRunLoop category method in test case code, but I'm not sure I'd recommend it for production use as it will use CPU heavily, though maybe changing to check every .1 second (or longer) would help, instead of using [NSDate date], which is a 0 interval.
- (BOOL)runWithTimeout:(NSTimeInterval)timeout untilCondition:(BOOL (^)(void))testBlock
{
NSDate *limitDate = [NSDate dateWithTimeIntervalSinceNow:timeout];
while (1)
{
if (testBlock())
return YES;
if ([NSDate timeIntervalSinceReferenceDate] > [limitDate timeIntervalSinceReferenceDate])
return NO;
if (![self runMode:NSDefaultRunLoopMode beforeDate:[NSDate date]])
return NO;
}
}
The more usual way to do a synchronous call with NSURLSession (in a subthread, I am assuming) is to use a semaphore:
dispatch_semaphore_t sem = dispatch_semaphore_create(0);
NSURLSessionDataTask* task = [session dataTaskWithRequest:request completionHandler:^(NSData *_data, NSURLResponse *_response, NSError *_error)
{
self->data = [_data retain];
self->tempResponse = _response;
self->tempError = [_error retain];
dispatch_semaphore_signal(sem);
}];
[task resume];
dispatch_semaphore_wait(sem, DISPATCH_TIME_FOREVER);
That may be complicated by the need to also check cancelled -- but you could make the semaphore an instance variable, and override the -cancel method to also call the semaphore. Make sure you don't use that semaphore instance again, as you could have multiple signals (and you may want to check self.isCancelled in the network completion block to make sure you don't do any additional work if previously cancelled).