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 think the real problem is that from the module's point of view
loading for autoreg is no different from loading for any other
purpose. In order to support unloading for autoreg, we'd need to
make unloading work in general. We simply don't know if any other
dll will use one of our registered factories even though we were
only loaded to do an autoreg. This means doing the per object
bookkeeping. And it means juggling of references from xpcom
itself to the component module so that they are either not
counted by the module in its determination of whether or not any
outsider is using *any* exported stuff, or xpcom would have to
release every reference it owns (except the one single reference
on the nsIModule) before asking if the module is unloadable. This
is a fairly big problem and it is distributed in a lot of DLLs.
The report that I heard from people who tried the repackaging
route (specifically jud) was that some modules in our system do
some strange things. There are a lot of special cases to deal
with. Getting unloading only a little bit wrong means a likely
later crash - and there is a lot of code that would need to be
touched to phase-in unloading.
For those asking about DLLs in jars... The implications vary from
OS to OS. In general this means having our code take over some of
the work that the OS does unloading libraries. This does not tend
to be trivial work. Doing so correctly can be very messy. This
can be a big task. And it is a wholly different task on each OS
family.
I think that buildtime control over packaging is the bast answer
(though certainly not easy - and plagued by its own set of
platform specific problems). Some work toward this was done on
Linux (and Win32?). I don't know much about Mac here. For those
other platforms it seems that building static libraries and then
stitching them together into DLLs (or one big EXE!) is the way to
go. This means the loss of "per DLL scope" as a namespace. Fixing
code that assumes that level of namespace was a big part of the
task that was at least partly done. The Other big issues I know
of are: making sure that the right code gets pulled into the DLLs
from the static libraries, making sure that the right symbols get
exported, (on Win32) there are efficiantcy issues having to do
with code that is either declared to be called in the same DLL,
but is called across DLL boundaries OR code that is declared to
be called across DLL boundaries, but ends up in the same DLL.
There are also issues with merging sets of xpcom registration
structures and other load-time behavior. I'm sure there are other
problems I don't know of. Some work was done, some not done. I
haven't heard anything about this lately. I didn't hear of any
work on Mac toward this goal. Was any done?
John.
>
> Simon
>
> --
> Simon Fraser Entomologist
> [EMAIL PROTECTED] http://people.netscape.com/sfraser/
