Go on. Explore!

lvl 0 • 0 xp

lvl 1

Home Market Decks Interests

Objective C Auto release pools

memorize.ai (lvl 286)

(0)

6 cards

()

Section 1

Preview this deck

What is Autorelease pool

Front

1 / 6

iOS Dev

0.0

0 reviews

5			0
4			0
3			0
2			0
1			0

Active users

All-time users

Favorites

Last updated

4 years ago

Date created

Mar 1, 2020

Cards (6)

Section 1

(6 cards)

What is Autorelease pool

Front

Autorelease pools provide a mechanism whereby you can send an object a "deferred" release message.

Back

Why exception handlers do not need to release objects that were sent autorelease.

Front

If an exception occurs, and the thread suddenly transfers out of the current context, the pool associated with that context is drained. However, if that pool is not the top pool on the thread's stack, all the pools above the drained pool are also drained (releasing all their objects in the process). The top autorelease pool on the thread's stack then becomes the pool previously underneath the drained pool associated with the exceptional condition. Because of this behavior, exception handlers do not need to release objects that were sent autorelease. Neither is it necessary or even desirable for an exception handler to send release to its autorelease pool, unless the handler is re-raising the exception.

Back

Uses of pool where you want to relinquish ownership of an object, but want to avoid the possibility of it being deallocated immediately (such as when you return an object from a method). Typically, you don't need to create your own autorelease pools, three occasions when you might use your own autorelease pools:

Front

command-line tool. inside loop secondary thread If you are writing a program that is not based on a UI framework, such as a command-line tool. If you write a loop that creates many temporary objects. You may create an autorelease pool inside the loop to dispose of those objects before the next iteration. Using an autorelease pool in the loop helps to reduce the maximum memory footprint of the application. If you spawn a secondary thread. You must create your own autorelease pool as soon as the thread begins executing; otherwise, your application will leak objects. (See "Autorelease Pools and Threads" for details.)

Back

How to create NSAutoreleasePool

Front

You create an NSAutoreleasePool object with the usual alloc and init messages, and you dispose of it with drain. An exception is raised if you send autorelease or retain to an autorelease pool. An autorelease pool should always be drained in the same context (such as the invocation of a method or function, or the body of a loop) in which it was created.

Back

Can you explain what happens when you call autorelease on an object?

Front

A: When you send an object a autorelease message, its retain count is decremented by 1 at some stage in the future. The object is added to an autorelease pool on the current thread. The main thread loop creates an autorelease pool at the beginning of the function, and release it at the end. This establishes a pool for the lifetime of the task. However, this also means that any autoreleased objects created during the lifetime of the task are not disposed of until the task completes. This may lead to the task's memory footprint increasing unnecessarily. You can also consider creating pools with a narrower scope or use NSOperationQueue with it's own autorelease pool. (Also important - You only release or autorelease objects you own.)

Back

When should thread detached thread use auto release pool

Front

If your application or thread is long-lived and potentially generates a lot of autoreleased objects, you should periodically destroy and create autorelease pools (like the Kit does on the main thread); otherwise, autoreleased objects accumulate and your memory footprint grows. If your detached thread does not make Cocoa calls, you do not need to create an autorelease pool.

Back