FROM : Jeff Disher
DATE : Sat Jan 11 17:50:27 2003
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_removed>
> 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_removed>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.
DATE : Sat Jan 11 17:50:27 2003
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_removed>
> 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_removed>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.
| Related mails | Author | Date |
|---|---|---|
| Stephane Thiell | Jan 11, 17:19 | |
| Jeff Disher | Jan 11, 17:50 | |
| Stephane Thiell | Jan 11, 18:39 | |
| Matthew Formica | Jan 13, 21:31 | |
| Chris Hanson | Jan 14, 00:55 |






Cocoa mail archive

