Re: Garbage collected and non-garbage collected
Re: Garbage collected and non-garbage collected
- Subject: Re: Garbage collected and non-garbage collected
- From: Bill Bumgarner <email@hidden>
- Date: Tue, 10 Mar 2009 11:06:17 -0700
On Mar 10, 2009, at 10:46 AM, I. Savant wrote:
Unfortunately this is true. Not just for frameworks, but any
plug-ins those frameworks might load.
A new, small internal project started awhile back seemed like the
perfect opportunity to try out GC in a production app. This app used
QTKit, but users needed the Flip4Mac plug-in to work with WMA files.
At the time (I have no idea about now), any time QuickTime tried to
load the Flip4Mac plug-in, it would die horribly. I reverted to good
old-fashioned memory management for two reasons:
Generally, a GC incompatibility shouldn't die a horrible death. If a
plug-in load is attempted and the plug-in's GC configuration
mismatches the application, dyld will refuse to load it. The one
'hole' is a pure-C plug-in that makes calls that trigger GCisms in
contexts where they shouldn't be; this is relatively rare, but QT
plug-ins is a known source of such issues.
The code needs to be compiled with GC enabled so that the correct
write barrier and layout information is emitted. And, of course, it
needs to be tested.
If you run across plug-ins that cause issues, you can do two things to
help address the issue:
(1) file a bug at http://bugreport.apple.com/ to make ADC/DTS aware of
the incompatibility
(2) give some feedback to the folks that make the plug-in that
indicates that you need GC support
b.bum
_______________________________________________
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