Re: ivar access during -finalize
Re: ivar access during -finalize
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 (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