Re: GC pros and cons
Re: GC pros and cons
- Subject: Re: GC pros and cons
- From: Quincey Morris <email@hidden>
- Date: Sun, 28 Jun 2009 10:17:16 -0700
On Jun 28, 2009, at 04:39, Michael Ash wrote:
On Sat, Jun 27, 2009 at 9:47 PM, Bill Bumgarner<email@hidden> wrote:
When a CF object is created, it is CFRetain()ed and, thus, the
collector
will ignore it. If it is then managed entirely through a balanced
set of
CFRelease() and CFRetain() calls, it'll work just like it does
under non-GC.
If you call CFMakeCollectable(), that'll effectively balance the
CFRetain()
at creation while making the collector aware of the object.
Thus, no real edge case here (as designed).
Right, but once you do the final CFRelease and the retain count hits
zero, objects in the default zone aren't destroyed, but merely become
eligible for collection. This modifies their lifetimes and may cause
their destruction code to run at a different time and in a different
context. This could conceivably cause trouble for CF containers with
custom callbacks that were built with the assumption that they would
run synchronously with the final CFRelease.
I think the answer is in Bill's "entirely", above.
Without CFMakeCollectable, the final CFRetain will trigger the calling
of (a hypothetical) CFDispose with the traditional timing (i.e.
immediately, we assume, somewhat at our peril).
After CFMakeCollectable in a GC-enabled environment, the final
CFRetain (if there is one, if the retain count was greater than 1 at
the time CFMakeCollectable was called) will just discard *the* strong
reference that the retain count was maintaining. This will trigger the
calling of (a hypothetical) CFFinalize with the usual timing (i.e.
when the collector runs, after there are no other strong references
remaining).
Thus GC-unaware code gets the behavior at CFRelease time that it
expects (somewhat at its peril), whether or not it is running in a GC-
enabled environment.
_______________________________________________
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