Is it necessary to create a new NSAutoreleasePool in detached threads ?
16/06/04 09:36
How to use correctly NSAutoreleasePool in NSThread ?
What is the best strategy ?
What is the best strategy ?
To allocate one or more NSAutoreleasePool is necessary if and only if, your NSThread code use Objective-C objects that are autoreleased (which is common if you are calling methods from Foundation or AppKit).
You will see a lot of example code allocating a "global" pool in the "main" function of the thread.
While this solution guarantees that you will not get any more warning about autoreleased objects not being in any pool, this doesn't mean it is the best solution!
What really does the threaded task and how it does it are much more important:
If your thread is just a way to make a small task to be executed asynchronously and then exit, it is ok to allocate a global autoreleased pool, BUT if you thread is a kind of "server" that will live in the background "forever", you better choose a more refined strategy.
Why ? Because every autoreleased object will actually be released ONLY when your thread exits, and if the thread "never" ends (think of a HTTP server as an example...) your autoreleased objects will "never" be released...
In other words, more your code use autoreleased objects more your application will be memory hungry...
In that kind of situation, you need to allocate (and release) the NSAutoreleasePool object "closer" to the code allocating temporary objects. Somewhere you are sure the [pool release] will actually be executed at regular interval...
Of course, finding the "best" place may require some profiling of your code and an analysis of its memory allocation pattern...
You will see a lot of example code allocating a "global" pool in the "main" function of the thread.
While this solution guarantees that you will not get any more warning about autoreleased objects not being in any pool, this doesn't mean it is the best solution!
What really does the threaded task and how it does it are much more important:
If your thread is just a way to make a small task to be executed asynchronously and then exit, it is ok to allocate a global autoreleased pool, BUT if you thread is a kind of "server" that will live in the background "forever", you better choose a more refined strategy.
Why ? Because every autoreleased object will actually be released ONLY when your thread exits, and if the thread "never" ends (think of a HTTP server as an example...) your autoreleased objects will "never" be released...
In other words, more your code use autoreleased objects more your application will be memory hungry...
In that kind of situation, you need to allocate (and release) the NSAutoreleasePool object "closer" to the code allocating temporary objects. Somewhere you are sure the [pool release] will actually be executed at regular interval...
Of course, finding the "best" place may require some profiling of your code and an analysis of its memory allocation pattern...