My Application structure is as follows, the core part is written in C++ and using thread heavily, and i am developing UI in Objective C on top of it, if i don\'t execute the t
See these docs for what you should know about multithreading with Cocoa: http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/Multithreading/ThreadSafetySummary/ThreadSafetySummary.html
It's OK to design your app like you have, but two things should be kept in mind:
Like so:
- (void)backgroundThreadStart
{
NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];
// do stuff
[pool release];
}
That will fix your console errors, but you might have other issues that led to the actual crashing you were seeing.
It means you autoreleased something without an autorelease pool in place.
Every thread has a stack of autorelease pools. On the main thread, an autorelease pool is created for you before Cocoa calls out to your code, and drained after your code returns. Every object you autorelease (whether explicitly or implicitly) goes into the pool, so that the pool will release it when the pool gets drained. When you create a thread, you have to create and drain an autorelease pool on that thread yourself. (Or just not autorelease anything, but that's practically impossible for any meaningful amount of code.)
If you ever decide to run your code under garbage-collection, you'll need to send the pool drain
, not release
, when you're done with it, for the pool to be useful. When GC is enabled, release
and autorelease
messages do nothing—they don't even go through. Your autorelease pool will respond to drain
by poking the garbage collector, which is the nearest equivalent to releasing the objects that would have been in the pool.
The Memory Management Programming Guide for Cocoa has more information about autorelease pools, among other things.