Please excuse the exceptionally long name but it fairly well describes the problem. I’m experiencing an odd situation where I’m using NSFileHandle to read data in the background and notify a delegate. Once data is received, the delegate creates an object representing the data and does its stuff and releases the object when it is done. Unfortunately, the object is not released if the application is in the background. If I click on the application, dealloc gets called on all the objects that were meant to be released. I assume that it’s a threading issue due to using readInBackgroundAndNotify but that’s only a guess. Everything else appears to operate in that thread except for the auto-generated autorelease pool isn’t being called. Is there a sufficient workaround and/or is there a way to flush the autorelease pool without having the user bring the application to the front?
-G
What autogenerated autoreleasepool? I may be wrong but I think that only the main thread gets an autoG autoRP. -JJ
Quoth the documentation: Each thread in a Cocoa application maintains its own stack of NSAutoreleasePool objects. When a thread terminates, it automatically releases all of the autorelease pools associated with itself. Autorelease pools are automatically created and destroyed in the main thread of applications based on the Application Kit, so your code normally does not have to deal with them there. If you are making Cocoa calls outside of the Application Kit’s main thread, however, you need to create your own autorelease pool. This is the case if you are a Foundation-only application or if you detach a thread.
There is a common bug in Cocoa apps in which the autorelease pool in the main thread isn’t drained unless there are events coming in. An easy fix is to generate do-nothing events in your main-thread code that runs while the app is in the background. For more information see:
http://www.mikeash.com/blog/pivot/entry.php?id=25#body
Regarding the page title, the title is not supopsed to describe the problem, it is supposed to name the page. The contents of the page are where you describe the problem.
See MailingListMode. In short, a page with such a huge title is unlikely to remain generally useful after the question has been answered, and as such will end up contributing nothing to the wiki. To avoid this, once the problem is solved, please move the content to another page with a better title (and clean it up so it looks like a reference, not a conversation), then delete this one.
Also, huge titles cause page expansion problems that make it hard to read for people with narrow browser windows like myself.
You could always set up your own autorelease pool and flush it every iteration through the loop, thereby avoiding the need for idle events.
Many thanks to the poster recommending the NSBlog entry, that’s exactly what I needed. As to the other two entries, I’m aware of how to use an autorelease pool but using NSFileHandle opens a thread that I’m not in control of and in which I don’t control that particular pool. Thanks just the same. As for the title, it was the shortest thing I could think of that still described the problem effectively. Since I’m satisfied with the replies, I’m happy to delete the page but it could be handy for someone else who falls into the same problem. Does anyone know of a better title or would this be better off put into a bullet point on a memory management page?
-G
If you want to write up a paragraph or two describing the problem and the solution, then give it its own page called something like AutoreleaseBackgroundLeaks, except better. If you think the blog post does it all and you just want to link to it, I’d stick it on NSAutoreleasePool or something of that nature. If you can, think about what you looked for before posting and see if you can put it someplace where somebody with the same problem would run across it.