[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: explain metaunloading to me, please
From:       Michael Matz <matz () ifh ! de>
Date:       2000-06-26 4:26:48
[Download RAW message or body]

Good night,

On Sun, 25 Jun 2000, Cristian Tibirna wrote:
> For the last 20-30 days I assisted with admiration and joy to the
> developments with a *very* high level topic in KDE's
> functionalities: metaclasses unloading.

:-)) Its not high level. Its only a chapter in the book "Matz: Things that
would be cool to have" (as Stephan put it) ;-)

> As a result, I've got a few questions that I'd really really like answered

OK, I will use DSO for dynamic shared object (all shared libraries and
modules, on a linux system "things whose name ends in .so" ;) and
dlopen'ed for the mechanism to load a DSO at runtime, and not at loadtime
(dlopen is called different on different platforms).

> a) what exactly made metaunloading necessary (my previous answer was
> kdeinit and Waldo's dynlib loading performance-increasing technology)

The answer depends on where you want to draw the line of responsibility.
Qt does not support unloading of dlopen'ed DSOs containing QObject
descendant classes C. The reason is: C has an associated metaclass. Of
that metaclass at most one object exists at runtime, called the meta
object (MO from here on). That MO is created the first time the
corresponding C is instantiated. All the MOs are collected in one
dictionary (objectDict), which is a global variable. That dictionary is
indexed by the classname of C. That name is a "const char *".

Because in the moc-genarated source the classname for class C is returned
like:
  const char *C::className() const { return "C"; }
the return value of that method points to the data segment of the DSO
containing that moc-file (in compiled form of course ;)) Furthermore there
are also other strings in those moc-files, and pointer to them are saved
into the MO. Now, when including a newly created MO into objectDict its
included under that key (::className()), but that string isn't copied, but
instead only the pointer to it.

Now consider, that such a DSO gets dlclose()'ed. Now _all_ pointers
holding an address to the datasection (and every other section) of that
DSO are invalid. This would normally be no problem, as a DSO should only
be unloaded if there are no other references to it. Unfortunately that
metaclass stuff is created by Qt slightly behind our back. Now if we
dlclose a DSO the MOs created by it remain in the objectDict. But the
pointers of the keys are already screwed, so the whole structure of that
dictionary is broken (e.g. a search for an item would look at some keys,
but as some of them are pointing into a black hole, the searcher would
happily follow them, and never come back).

We could now think, hey, simply don't install pointers to names as keys,
but first copy them into allocated memory, and store pointers to that.
That would work, and the structure of the dictionary would not be broken
after unloading. But as said above, also in the MOs itself are stored some
pointers to character arrays, so after unloading those MOs would be
broken. The only solution is, to remove all MOs from the dictionary. Of
course only those MOs which were really created by the DSO which is going
to become dlclosed.

So far for the reason ;)

> b) is there any overhead incumbed by the metaunloading? If yes, which?

Yes, there is an overhead ;) Exactly the time it takes to remove as many
objects from on QGDict, as there were QObject descending classes in a DSO.
This time is added to the time the dlclose call itself takes. I guess it
takes between 0.000 and 0.0000 seconds ;)

> c) is metaunloading of any interest for a non-cvs-kde app developer? if
> yes, what is to be known?

No and nothing. Well, OK, the said developer should use am_edit as that
(now) automatically creates all code as soon as there are any moc files
created for a project. If he doesn't use am_edit he should not expect that
his DSO can be unloaded. E.g. if he made a kpart he would loose, because
that gets unloaded. Anyway, everyone should use am_edit ;)

Ahh, and on HP-UX it does not work right now, as that platform is
unbelievable screwed in that respect. I know a solution, but I haven't yet
decided if its worth it, or if we shouldn't simply disable unloading DSOs
on HP-UX... Well, its some months till KDE 2, so I hope to have enough
time for the other platforms (I know, that it works on linux, Solaris (CC
and gcc), IRIX (CC and gcc) and probably all other ELF systems (at least
with gcc))

> d) what has to know a cvs-kde-app developer concerning using/not-using
> metaunloading ? In other words, when is metaunloading indispensable?

am_edit should take care of everything. As of today night, the unloading
code gets included automatically in every binary using moc files (yes,
also into kdecore or kedit) so the developer has simply not the option to
not use it. It does no harm (only spits out interesting debug output right
now), and if it makes problems its only an indication of other problems
somewhere. So essentialy nobody needs to care about it ;)


Ciao,
Michael.
PS: my mails seem to become long today, sorry ;)

[prev in list] [next in list] [prev in thread] [next in thread]