Do you need to create an NSAutoreleasePool within a block in GCD?
Does the same rule apply to a block that is placed within a Grand Central Dispatch queue and will be run on a non-main thread? That is, do you need to create an NSAutoreleasePool within each block you dispatch to anything other than the main queue?
Grand central dispatch will manage an autorelease pool per queue automatically. However, there are no guarantees as to when the pool will be drained; it may be after one block is processed, it may be after hundreds (but probably won't be).
So, if you are only allocating a few objects, don't worry about it. However, if you are allocating any significant number of objects (and since you are targeting a memory constrained environment), then you should be creating and draining pools.
The documentation has been updated.
If your block creates more than a few Objective-C objects, you might want to enclose parts of your block’s code in an @autorelease block to handle the memory management for those objects. Although GCD dispatch queues have their own autorelease pools, they make no guarantees as to when those pools are drained. If your application is memory constrained, creating your own autorelease pool allows you to free up the memory for autoreleased objects at more regular intervals.
Brad Larson
I'm currently an engineer at PassiveLogic, building Swift-based machine learning systems for optimizing complex control systems. We envision buildings as giant robots, and believe that more efficient control of these intricate systems can significantly reduce energy demand globally. Formerly, I was a member of the Swift for TensorFlow team at Google, exploring how machine learning could be advanced by integrating first-class support for differentiability into the Swift language. Many items we built there, such as differentiable Swift, live on in open source (differentiable Swift is a key component of our products at PassiveLogic). Prior to that, I was the CEO and cofounder of SonoPlot, Inc. SonoPlot manufactures and sells robotic systems for the printed electronics and biological research markets. I also used to do Mac and iOS development on the side via my one-man company Sunset Lake Software, with a particular focus on the iPhone and iPad. I released an open-source molecular modeler for Mac and iOS called Molecules, and plan to open source my former equation editor called Pi Cubed as well. I'm the author of an open source framework called GPUImage which lets you perform GPU-accelerated filtering of images and video on Mac, iOS, and Linux. I also taught a course on advanced iPhone development at the Madison Area Technical College, for which the fall and spring semesters' videos can be found on iTunes U. Class notes for this course (with links to sample code and other resources) can be downloaded here in VoodooPad format.
Updated on June 07, 2022Comments
-
Brad Larson about 2 years
Normally, if you spawn a background thread or run an NSOperation on an NSOperationQueue you need to create an NSAutoreleasePool for that thread or operation because none exists by default.
Does the same rule apply to a block that is placed within a Grand Central Dispatch queue and will be run on a non-main thread? That is, do you need to create an NSAutoreleasePool within each block you dispatch to anything other than the main queue?
In my limited testing, I don't see the console warnings for autoreleased objects that you normally see with background threads or NSOperations. However, I can't seem to find definitive documentation on this, so I was wondering if someone could point out where this is stated.
-
bbum over 13 yearsNot clearly enough. Documentation bug filed (<rdar://problem/8651175>).
-
Brad Larson over 13 yearsExcellent. Thanks for the clarification.
-
dennycd over 10 yearscan anyone provide the link the apple doc related to this one ? thankx -
bbum over 10 years@dennycd developer.apple.com/library/ios/DOCUMENTATION/General/… (Search for
autorelease).
