Re: Garbage collected and non-garbage collected
Re: Garbage collected and non-garbage collected
- Subject: Re: Garbage collected and non-garbage collected
- From: Greg Parker <email@hidden>
- Date: Wed, 11 Mar 2009 17:14:30 -0700
On Mar 11, 2009, at 4:31 PM, Robert Mullen wrote:
Approach 2 seems appealing but my initial go at it went less than
sterling. All access to the struct appears to be incorrect and
whereas most of the data contained before seemed to have integrity
now it almost immediately bombs with either EXC_BAD_ACCESS or it
gets an object other than what it was expecting. Which it gets is
pretty well random to my eyes making debugging a bit of an
adventure. What I did was to mark all the pointer types in the
struct with __strong so where it used to look like:
[...]
Good.
I then changed the calloc()s to use NSAllocateCollectable:
_SM2DGraphView_Private = calloc( 1, sizeof(SM2DPrivateData) );
becomes
_SM2DGraphView_Private = NSAllocateCollectable(sizeof
(SM2DPrivateData), NSScannedOption);
The collector treats this struct as a garbage-collected block, which
won't work unless you find all pointers to this struct and make the
same __strong / NSAllocateCollectable changes to them. If you add
NSCollectorDisabledOption, then this struct works more like ordinary
memory that you have to free() by hand.
In particular, the code I found on the Internet has
_SM2DGraphView_Private as a void* ivar. The collector does not look
for GC pointers inside void* ivars, so without
NSCollectorDisabledOption it'll throw the object away. Either add
NSCollectorDisabledOption() and free() the struct later; or make
_SM2DGraphView_Private a `__strong void *` and don't free it; or make
SM2DPrivateData a real Objective-C class and _SM2DGraphView_Private an
`SM2DPrivateData *`.
(Should this be _SM2DGraphView_Private = (SM2DPrivateData *)
NSAllocateCollectable(sizeof(SM2DPrivateData), NSScannedOption);
instead?)
Doesn't matter for GC purposes.
and assignment to the struct members is done like this:
myPrivateData->borderColor = [ [ NSColor blackColor ] retain ];
Do I need to remove the copy and retain semantics from each of these
as well? I was under the impression that the GC would just ignore
these since it was using its own cleaning mechanism and that they
could be left as is.
You're correct. -retain is ignored when GC is on. (CFRetain is not
ignored. If there are any CFRetain or CFRelease calls in the code, or
any CFCreate or CFCopy calls, then you may need more work to make
retain counts balance. CFRetain and -retain are not toll-free under GC.)
I am not sure where to go from here. I beat my head against it a
fair bit today and am learning more about GC and non-GC code but am
struggling to get over the hump. I am going to crack open the
Hillegass book again tomorrow and reread the GC chapter in hope that
a light bulb will go off. From what I read today though I would have
thought the above would have worked.
Interfacing GC code with ordinary C code is hard. There are lots of
holes to fall into, and it's hard to tell where they are until you
crash.
--
Greg Parker email@hidden Runtime Wrangler
_______________________________________________
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