Threading Programming Guide
Thread Management
Writing Your Thread Entry Routine
1 Creating an Autorelease Pool
Applications that link in Objective-C frameworks typically must create at least one autorelease pool in each of their threads. If an application uses the managed model—where the application handles the retaining and releasing of objects—the autorelease pool catches any objects that are autoreleased from that thread.
If an application uses garbage collection instead of the managed memory model, creation of an autorelease pool is not strictly necessary. The presence of an autorelease pool in a garbage-collected application is not harmful, and for the most part is simply ignored. It is allowed for cases where a code module must support both garbage collection and the managed memory model. In such a case, the autorelease pool must be present to support the managed memory model code and is simply ignored if the application is run with garbage collection enabled.
If your application uses the managed memory model, creating an autorelease pool should be the first thing you do in your thread entry routine. Similarly, destroying this autorelease pool should be the last thing you do in your thread. This pool ensures that autoreleased objects are caught, although it does not release them until the thread itself exits. Listing 2-2 shows the structure of a basic thread entry routine that uses an autorelease pool.
Listing 2-2 Defining your thread entry point routine
|
- (void)myThreadMainRoutine |
|
{ |
|
NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init]; // Top-level pool |
|
|
|
// Do thread work here. |
|
|
|
[pool release]; // Release the objects in the pool. |
|
} |
Because the top-level autorelease pool does not release its objects until the thread exits, long-lived threads should create additional autorelease pools to free objects more frequently. For example, a thread that uses a run loop might create and release an autorelease pool each time through that run loop. Releasing objects more frequently prevents your application’s memory footprint from growing too large, which can lead to performance problems. As with any performance-related behavior though, you should measure the actual performance of your code and tune your use of autorelease pools appropriately.
detachNewThreadSelector:toTarget:withObject:
Detaches a new thread and uses the specified selector as the thread entry point.
+ (void)detachNewThreadSelector:(SEL)aSelector toTarget:(id)aTarget withObject:(id)anArgument
Parameters
aSelector
The selector for the message to send to the target. This selector must take only one argument and must not have a return value.
aTarget
The object that will receive the message aSelector on the new thread.
anArgument
The single argument passed to the target. May be nil.
Discussion
For non garbage-collected applications, the method aSelector is responsible for setting up an autorelease pool for the newly detached thread and freeing that pool before it exits. Garbage-collected applications do not need to create an autorelease pool.
The objects aTarget and anArgument are retained during the execution of the detached thread, then released. The detached thread is exited (using the exit class method) as soon as aTarget has completed executing the aSelector method.
If this thread is the first thread detached in the application, this method posts the NSWillBecomeMultiThreadedNotification with object nil to the default notification center.
Availability
Available in iOS 2.0 and later.