Re: NSAutounbinder not releasing my object in a timely manner
Re: NSAutounbinder not releasing my object in a timely manner
- Subject: Re: NSAutounbinder not releasing my object in a timely manner
- From: Ken Thomases <email@hidden>
- Date: Thu, 19 Jul 2012 16:38:11 -0500
On Jul 19, 2012, at 6:02 AM, Jonathan Taylor wrote:
> - User requests batch processing of data within a folder tree, which will result in between 0 and many separate movies being generated.
> - Application allocates a "progress" tracker, subclassed from NSWindowController, in control of a window containing a progress indicator and various other feedback elements.
> - This is supplied to separate traversal/parsing code which identifies source data from which movies should be generated.
> - For each movie to be generated, the progress indicator is retained in association with a GCD block which will be executed to perform the actual work, added to a serial queue
> - Following tree traversal, the application releases its reservation on the progress tracker. If no movies are due to be generated, I had intended this to cause it to be deallocated, at which point I had been closing the window.
>
> If work was queued, this will in due course be executed. The current work block will take control of updating the progress tracker. When it is finished it will release its reservation of the progress tracker. Again, when all work has been completed I intended the retain count to fall to zero at which point it would be deallocated and closed.
> Now, your statement that "[you shouldn't be] relying on an object being deallocated to change your GUI" seems fair, but how would you tackle my scenario here?
This sounds like a job for a dispatch group. Schedule all of the blocks using one of the dispatch_group_[a]sync() functions. Set up a block to be performed when they are all completed using dispatch_group_notify().
> One possible solution would be to have an intermediary object with no gui/binding/etc of its own, which allocates and owns the progress window and is retained and released by my code as necessary, closing/releasing the window when it is deallocated. In practice, I suspect that would work because that intermediary object "shouldn't" get caught up in any of the deferred autoreleasing that was associated with my original problem.
I would expect it to have exactly the same problem.
> However I am genuinely not sure whether that is just a slightly more indirect way of violating your advice, or whether it is acceptable. I guess I am not sure whether your statement is a generic design principle or a practical rule of thumb for avoiding the sort of issue I encountered.
I would say it's a general principle. Deallocation is for releasing resources. Don't predicate any behavior of your program which is not related specifically to resource management on deallocation. Ideally, you wouldn't even wait for deallocation to release resources. It's been Apple's advice for a while, for example, to explicitly close a file handle when the code which owns the file handle knows it's done with it. Don't just leave it to dealloc.
> In my mind retain/release is a way of tracking the interest that my different work packages have on the progress window.
No, it's a way of tracking ownership of the resource, which is slightly different. Of course an object should keep ownership of the progress window for as long as it "has an interest" in it, but that's not what it truly represents. You're currently dealing with the case where the two diverge.
> If you say you don't like my intermediary object approach then my next proposal will be that I implement a "manual" counter of the number of work packages outstanding... which is really just me reimplementing a parallel retain/release mechanism myself. Is *that* more acceptable, or am I again violating the spirit if not the letter of your statement?
I don't consider myself any sort of arbiter of these things, so "acceptable" isn't the right word, but I don't have any problem with that. First, your mechanism would presumably not have anything like autorelease. Second, since it's not a mechanism that the rest of Cocoa will participate in, you don't get other code implicitly and/or unwittingly changing the behavior of your code. Finally, it won't be a mechanism with another, unrelated semantic purpose that you'd be overloading.
Regards,
Ken
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden