Question

I use performSelectorInBackground to do calculations on a background thread to keep the main thread responsive to UI tasks. This used to work on iOS4 but seems to cause issues on iOS5. It seems that the background thread would sometimes finish successfully and report back the result and sometimes it just dies silently without an exception or other trace.

I’m wondering if there were any changes in iOS5 which have caused performSelectorInBackground to behave in an unreliable manner ?
Or is there some better alternative to performSelectorInBackground that I am not aware of ?

NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];

[self.earningsController performSelectorInBackground:@selector(calculateTotalEarnings:) withObject:[NSNumber numberWithInt:_startAmount]];

[pool drain];

-------------------------------------------------------

-(NSDecimalNumber*)calculateTotalEarnings:(NSNumber*)startAmount
{
    NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];

    NSDecimalNumber *retValue = [NSDecimalNumber zero];

    @try 
    {
            retValue = [self calculateTotalsWithNumber:startAmount];

        // Post a Notification with calculated totals
         [[NSNotificationCenter defaultCenter] postNotificationName:TOTAL_EARNINGS_CALCULATED object:retValue];

    }
    @catch (NSException * e) 
    {
            NSLog("Exception: %@", [e reason]);  // never gets here
    }

    [pool release];

    return retValue;
}

Answer 1

I wouldn’t focus exclusively on changes in performSelectorInBackground, rather I would look into your method “calculateTotalsWithNumber:” to see if it is behaving differently under iOS5. If your thread is dying sporadically then there may be something awry in its implementation causing the death. Also I would look elsewhere in your project to see if somehow another code could be interfering with the task. While it’s possible that the API changed slightly in a way that would cause background logic to die it’s not likely as millions of apps use this I’d guess. Go for something more likely such as a race condition or an unprotected iVar that needs guarding by some sort of mutex or lock.