Re: Cocoa classes and plug-in bundle (dylib) in-memory lifetimes (AU, x64, ObjC)
Re: Cocoa classes and plug-in bundle (dylib) in-memory lifetimes (AU, x64, ObjC)
- Subject: Re: Cocoa classes and plug-in bundle (dylib) in-memory lifetimes (AU, x64, ObjC)
- From: Paul Davis <email@hidden>
- Date: Sat, 09 Apr 2011 09:12:55 -0400
On Sat, Apr 9, 2011 at 8:42 AM, Angus F. Hewlett <email@hidden> wrote:
> Hi all,
>
> Apologies for cross-posting - having some difficulty getting a definitive
> answer on this one.
>
> Trying to clarify the runtime behaviour of Cocoa-UI-based AU bundles, in
> relation to module load & unload, and what the correct behaviour should be.
>From the NSBundle reference, you'll find half of your answer:
----------------
NSBundle load
....
You can use this method to load the code associated with a dynamically
loaded bundle, such as a plug-in or framework. Prior to Mac OS X
version 10.5, a bundle would attempt to load its code—if it had
any—only once. Once loaded, you could not unload that code. In Mac OS
X version 10.5 and later, you can unload a bundle’s executable code
using the unload method.
NSBundle unload
....
Prior to Mac OS X version 10.5, code could not be unloaded once
loaded, and this method would always return NO. In Mac OS X version
10.5 and later, you can unload a bundle’s executable code using this
method.
------------------
Its not entirely clear if this means that the code is not unloaded
even if the last reference to the bundle is destroyed. But it certain
does mean that in Ardour and all the source-code viewable code that we
had to base stuff on, we simply create a new NSBundle with [NSBundle
bundleWithPath] and nothing more. ever. I confess to not even being
sure of the lifetime/scope of the bundle so created.
--p
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden