In article <93v30l$[EMAIL PROTECTED]>, "Ken Kozman"
<[EMAIL PROTECTED]> wrote:
> So I was interested by this post and went and looked at the Mozilla source
> some.
>
> There seems to be no reason why after self-registering a DLL (shared
> library, whatever) that that DLL can not be immediately unloaded out of
> memory. It actually (from my brief foray into the code) looks like this was
> the intention, but that it was not followed up on.
>
> There is the canUnload( ) call in nsIModule which is used to make sure the
> given DLL has no external references, this will allow that DLL to be
> unloaded (if it has no outstanding references.) I traced around the code in
> nsNativeComponentLoader.cpp and found the call to SelfRegisterDll( ) which
> is called by all the auto-registration pieces.
>
> The header for this method (with comments) is:
>
> /*
> * SelfRegisterDll
> *
> * Given a dll abstraction, this will load, selfregister the dll and
> * unload the dll.
> *
> */
> nsresult
> nsNativeComponentLoader::SelfRegisterDll(nsDll *dll,
> const char *registryLocation,
> PRBool deferred)
>
> But inside the code it does not actually unload the dll (though it does load
> it and self-register it.)
>
> So it is my belief that any DLL which is loaded by this at autoregister time
> (which I think is any new/modified DLL, and any DLLs registered as being a
> deferred component) will not be unloaded.
>
> Maybe I'm not seeing the forest for the trees or something here...
You're absolutely right here. The missing part of the picture is
that we've never unloaded DLLs before, so it's probably the case
that many DLLs will do bad things (crash etc) if unloaded. Certainly,
we know that almost all of them simply return FALSE from their
CanUnload methods. But perhaps if they were only loaded to be
registered, then unloading would be OK.
Simon
--
Simon Fraser Entomologist
[EMAIL PROTECTED] http://people.netscape.com/sfraser/
