At 10:39 15/01/2001 -0800, Simon Fraser wrote:
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.

I would have hoped that unloading would have been part of the test suite of any particular DLL, there are going to be a number of DLLS which are never going to get unloaded of course and with the interconnections a great many will be mutually or secondarily addref'd.  Not for the first time I feel like the number has been screwed to the door before the footings were in place.

Simon


Simon

--
          Simon Fraser   Entomologist
  [EMAIL PROTECTED]   http://people.netscape.com/sfraser/


 Beware knowledge cheaply gained for in the spending of it you may pay more than its worth.
 S. P. Lucy

Reply via email to