Re: ivar access during -finalize
Re: ivar access during -finalize
- Subject: Re: ivar access during -finalize
- From: Quincey Morris <email@hidden>
- Date: Sun, 11 Mar 2012 00:01:33 -0800
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. :)
** Apart from retain cycle issues, the code for GC and ARC is basically the same.
_______________________________________________
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