Re: Module unlinking
Re: Module unlinking
- Subject: Re: Module unlinking
- From: Matthew Formica <email@hidden>
- Date: Mon, 13 Jan 2003 12:31:39 -0800
Take a look at NSBundle, CFBundle, and CFPlugin (and the docs for those).
We certainly allow for unloading modules, but you don't have to use such a
low-level API to do it.
- Matthew
On 1/11/03 9:39 AM, "Stephane Thiell" <email@hidden> wrote:
>
Thank you Jeff for your bright reply,
>
>
I understand now a bit more the problem. That's unfortunate (for
>
me... I know that plugins are not usually unloaded). The core of my
>
app connects to servers, authenticates, keeps essential data etc..
>
modules perform misc. calculations, interactions and operations on
>
these data... so installing and reloading modules at runtime is very
>
useful for development and frequent upgrades. Because they are small
>
modules and might be reloaded few times per day only, I would be OK
>
to just let them leak. However I can't find any error handlers
>
installer for unlinking modules. I only found
>
NSInstallLinkEditErrorHandlers() but it's only called for linking
>
conflicts/errors. Failed unlink always crash. So I need now to
>
discover if a linked module is in objC or not. If it is, I can't call
>
NSUnLinkModule. How? I don't know yet. ;)
>
>
Regards,
>
Stephane Thiell
>
>
>
> I was looking into the behavior of unlinking bundles and I seem to
>
> remember turning up the conclusion that you cannot unlink modules
>
> with Obj-C data.
>
>
>
> This didn't really surprise me because the runtime has to be
>
> modified when you load a module (to take this example to an extreme,
>
> think about categories). This would imply that you would have to
>
> roll-back the runtime to a previous state when unlinking a module.
>
> That sounds somewhat simple unless you don't unlink them in reverse
>
> order of how you originally linked them.
>
>
>
> I would be pleasantly surprised if someone corrected me on this but
>
> the capability to unload things dynamically is pretty tricky and not
>
> really useful in practice. Apple isn't the only one cutting corners
>
> here, even Linux is losing kernel module unloading capabilities
>
> soon. It complicates things too much to be practical.
>
>
>
>
>
> Hope that helps,
>
> Jeff.
>
>
>
> On Saturday, January 11, 2003, at 11:19 AM, Stephane Thiell wrote:
>
>
>
>> Hello,
>
>>
>
>> I'm new to Cocoa development. I wrote a daemon program which is
>
>> highly modular, and add modules at runtime or reload them after
>
>> change. It's written in C++ and is linked with CoreFoundation
>
>> framework. I wrote recently a new module loader (not in objC) with
>
>> NSModule to link and unlink C or C++ modules. It works like a
>
>> charm, until I wanted to try cocoa/objC support in modules
>
>> (strongly requested by some Cocoa developers friends):
>
>>
>
>> 2003-01-11 16:55:51.076 Craw[3508] _CrawModuleDestroy
>
>> objc: cannot unmap an image containing ObjC data
>
>> (and then crash)
>
>>
>
>> from 'man NSModule' :
>
>>
>
>> NSUnLinkModule unlinks the specified module handle from
>
>> the program. Currently the implementation is limited to
>
>> only allow modules linked with NSLinkModule to be
>
>> unlinked. The parameter, options, can have a set of
>
>> options or'ed together.
>
>>
>
>> Our modules are always linked with NSLinkModule. Additionnaly, I
>
>> tried NSUNLINKMODULE_OPTION_NONE and
>
>> NSUNLINKMODULE_OPTION_KEEP_MEMORY_MAPPED options without success...
>
>> Nothing in the manual about objC limitation.
>
>>
>
>> I need help on how to do it, or unfortunately, I'll be on the way
>
>> to forget Cocoa support. I probably did something wrong, I can't
>
>> think a so dynamic language has such a limitation. It would be so
>
>> great to have it in the plugins. :-(
>
>>
>
>> Thanks in advance,
>
>> --
>
>> Stephane Thiell
>
>> _______________________________________________
>
>> cocoa-dev mailing list | email@hidden
>
>> Help/Unsubscribe/Archives:
>
>> http://www.lists.apple.com/mailman/listinfo/cocoa-dev
>
>> Do not post admin requests to the list. They will be ignored.
>
>>
>
> Jeff Disher
>
> President and Lead Developer of Spectral Class
>
> Spectral Class: Shedding Light on Innovation
>
> http://www.spectralclass.com/
>
_______________________________________________
>
cocoa-dev mailing list | email@hidden
>
Help/Unsubscribe/Archives:
>
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
>
Do not post admin requests to the list. They will be ignored.
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.