NSAutoreleasePool,
as the document says, “if you detach a thread — you need to create your own autorelease pool.”
Previously，I thought when detach a thread, it maybe cause memory leaks, but when I was testing, there was no leaks.
So how to explain The document? Does it still need a autorelease pool?
Can you help me? Thanks very much!
Related
I'm creating a new thread using detachNewThreadSelector ref with toTarget self.
The purpose of the thread is to poll movements and load images as appropriate - it loops and only quits when an atomic bool is set to true in the main thread - which is set in the objects dealloc.
The problem is caused by this (from the detachNewThreadSelector reference):
The objects aTarget and anArgument are retained during the execution of the detached thread, then released
Which means my object will always have a (minimum) retain count of one - because the thread continuously polls. dealloc is therefore never called.
So my question is: how can I dealloc my object taking into account the existence of the polling thread?
The only idea I have right now is to create a destroyThread function of the object, which sets the end thread bool, which would be called from everywhere I'd expect the object to be destroyed. This seems error-prone, are there better solutions?
Thanks in advance.
Update
I had an idea for another solution - in the thread I detect if the retain count is one - if it's one then I know the thread is keeping the object alive, so I break the loop and dealloc is called. Is this a robust solution?
First, avoid detachNewThreadSelector:. Anything you are thinking of doing with it is almost certainly done better with a dispatch queue or NSOperationQueue. Even if you need to manually create a thread (which is exceedingly rare in modern ObjC), it is better to create explicit NSThread objects and hold onto them rather than using detachNewThreadSelector: which creates a thread you can't interact directly with anymore.
To the specific question, if you create your own threads, then you'll need to set that bool somewhere other than dealloc. That means that some other part of the program needs to tell you to shut down. You can't just be released and automatically clean yourself up using manual threads this way.
EDIT: Never, ever call retainCount. No solution involving retainCount is a good solution. Putting aside the various practical problems with using retainCount in more general cases, in this case it ties you manual reference counting. You should switch to ARC as quickly as possible, and retainCount is illegal in ARC (it should have been illegal before ARC, but they finally had a really good excuse to force the issue). If you can't implement your solution in ARC, it is unlikely a good solution.
Again, the best solution is to use GCD dispatch queues (or operations, which are generally implemented with dispatch queues). It is incredibly more efficient and effective for almost every problem than manual thread management.
If you must use a manual thread for legacy code and need to maintain this kind of auto-destruct, the solution is a helper object that owns the thread. Your object owns the helper object, which has a retain loop with the thread. When your object is deallocated, then it tells the thread to shut down, which breaks the retain loop, and the helper object goes away. This is a standard way of managing retain loops.
See Apple's Migrating Away From Threads for more.
Consider we are implementing our own thread with lot of autoreleased object. Is it mandatory to use autorelease pool on this scenario if yes/no why?
It's mandatory to have an autorelease pool on any thread that you create, because Cocoa internals expect there to be one in place and you will leak memory if it isn't there.
Cocoa always expects there to be an autorelease pool available. If a pool is not available, autoreleased objects do not get released and your application leaks memory. If you send an autorelease message when a pool is not available, Cocoa logs a suitable error message.
Applications that link in Objective-C frameworks typically must create at least one autorelease pool in each of their threads.
It is mandatory even with a single autoreleased object, because otherwise it will leak.
Language : Objective C
Questions:
why we should always use 'drain' over 'release' for an autorelease pool ?
what will happen if [pool retain]; ? why ?
what will happen if [pool autorelease]; ? why ?
The documentation doesn't give a direct answer to this. However, there is a very clear answer; because it doesn't make sense.
P.S: drain and release are the exact same thing on an autorelease pool.
Under garbage collection, release acts as a no-op, whereas drain triggers garbage collection, and then release (which is unusual), so drain should be the preferred way of emptying a pool. retain and autorelease are intentionally disabled, as per the documentation.
WWDC 2011 Session 323, Introducing Automatic Reference Counting, explains that autorelease pools are not real objects, so they cannot be retained. Retaining an autorelease pool will cause an exception. Watch the video at 24:27 or read slide 23 of the Keynote. You must be a registered developer to access.
Under ARC, autorelease syntax is a scoped block of code preceded by #autorelease. According to Apple, this syntax more accurately describes what autorelease does under the hood.
How can I kill a thread created by performSelectorInBackground:withObject: from the main thread? I need to force termination of freezing threads.
You cannot kill background threads from the main thread, the method that is executing in a background thread has to return for the thread to end.
Your actual problem seems to be that your background thread is freezing, you should solve that instead of trying to work around it.
I'm not sure if this may help but here goes:
Assuming you're calling that performSelector call from class A. And assuming that class A is about to be released from memory in class B (which is where if the selector hasn't been performed yet, you might be getting a crash - Hence you're posting this question on SO):
Wherever you're releasing A from B, do this:
[NSObject cancelPreviousPerformRequestsWithTarget:A];
Apple documentation says
The recommended way to exit a thread is to let it exit its entry point
routine normally. Although Cocoa, POSIX, and Multiprocessing Services
offer routines for killing threads directly, the use of such routines
is strongly discouraged. Killing a thread prevents that thread from
cleaning up after itself. Memory allocated by the thread could
potentially be leaked and any other resources currently in use by the
thread might not be cleaned up properly, creating potential problems
later.
Normally when you create an NSOperation subclass you are responsible for creating and releasing an NSAutoreleasePool in the -main method.
When you use an NSBlockOperation, do you need to create an autorelease pool in the block?
No. GCD (which NSOperationQueue is built on top of as of OS X 10.6 or iOS 4.2) manages autorelease pools for you, the same way that NSRunLoop does.
I don’t think so, as the work queues have their own pools already created for you.
Adam,
Your best bet is to read up on block memory behavior with objects. Here is the link for the iOS Blocks and Variables the bottom of this page has information regarding object types.
Frank