On 11 Mar 2012, at 08:01, Quincey Morris wrote: > On Mar 10, 2012, at 23:18 , Eric Wing wrote: > >> I don't disagree that finalizers are hard and need to be approached >> with great care. And I agree that all 4 of your points are valid. >> However, I think this description of the retain cycle problem might be >> a little over-dramatic. Retain cycles have always been a problem in >> classic memory management and are still a problem even under ARC. Yet >> there is over a decade's worth of code that managed to write code to >> the Cocoa framework and for the most part avoid retain cycles. With a >> simple scoped problem, well defined strategy, and some care, I think >> this is entirely doable. And if he were to go manual management or >> ARC, he has to avoid retain cycles anyway so he still has to design >> carefully. > > I think I'd put it this way: > > There's a difference between a retain cycle in a retain/release (RR) app and > a retain cycle introduced into a GC app by using CFRetain. > > In the first case, the app is architected so that cycles are manually broken > in cases where that's necessary. > > In the second case, the app was previously architected to *ignore* any > question of cycles, since normally they're irrelevant to GC. By using > CFRetain, the question is no longer irrelevant, and the app may need to be > re-architected, and the changes may not be local to the places where CFRetain > is explicitly used. On top of that, in a GC app, you aren't in control of all > of the code (you're using Cocoa frameworks, other frameworks and libraries, > whose internal use of references is unknown and unmanageable). > > At risk of making another sweeping generalization, I'd say that spending your > time on doing complicated things with finalization is a terrible waste of > resources. > > The finalization/resource-disposal problem is the *big* drawback to GC apps. > Retain cycles are the *big* drawback to ARC apps. Both of them require > considerable design and implementation effort to solve. In Jonathan's case, > using CGRetain would mean he has to solve *both* at the same time. If he > can't solve the finalization problem more directly, he'd probably be better > off re-architecting the app for ARC and just dealing with the cycles**. > > But, as I noted before, he could be lucky in using your suggestion. It might > be two small problems instead of two big problems. :)
I think both Eric an Quincey are making valid points. Unrestrained use of CFRetain/CFRelease in a GC app could certainly lead to trouble. It could also be used with restraint, what is probably what Eric had in mind. The category disposal counting solution that I proposed certainly works. It has some advantages: 1. Resource disposal isn't tied to the object lifetime so disposal is predictable. 2. It doesn't require any code in -finalize. The downsides are: 1. What is essential (in my case) an internal class resource management problem leaks out into the application space as I have to explicity manage the disposal count. 2. A failure to balance the disposal retain/release calls will leak data in temporary files - which may be a big deal depending on the content. My conclusion: 1. The CFRetain/CFRelease solution is elegant and will I think suffice for my admittedly simple scenario. 2. Under GC CFRetain/CFRelease use the GC ref counting mechanism so we are still working with the central GC memory management system. 3. I will be applying the retain/release to ivars which *should* never reference self so retain cycles should not be a problem. I agree with Quincey though that a complicated -finalize method is probably a bad -finalize method. Regards Jonathan Mitchell Mugginsoft LLP _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
