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

List:       kde-core-devel
Subject:    Re: explain metaunloading to me, please
From:       Waldo Bastian <bastian () kde ! org>
Date:       2000-06-26 5:23:55
[Download RAW message or body]

On Sun, 25 Jun 2000, Cristian Tibirna wrote:
> Hello
>
> 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. For a while, I thought I
> understand clearly most of the implications and aspects of this useful
> technology.
>
> Yet, this evening, I realized the performance to detach myself from the
> perception of a continual KDE observer and put myself in the position of
> an external developer that targets his application to KDE-2.
>
> As a result, I've got a few questions that I'd really really like answered
> (Michael Matz, I look at you with hope :-))  :
>
> a) what exactly made metaunloading necessary (my previous answer was
> kdeinit and Waldo's dynlib loading performance-increasing technology)
>
> b) is there any overhead incumbed by the metaunloading? If yes, which?
>
> c) is metaunloading of any interest for a non-cvs-kde app developer? if
> yes, what is to be known?
>
> d) what has to know a cvs-kde-app developer concerning using/not-using
> metaunloading ? In other words, when is metaunloading indispensable?

Let me first give a general answer and then answer your questions one by one 
as far as I know the answers.

The basic problem is that when we unload a Dynamically loaded Shared Object 
(DSO, e.g. a dlopen'ed library) we must make sure that there are no longer 
any references to any data of code that is part of this DSO because after 
unloading the DSO, such a reference will point into void and will cause a 
crash sooner or later.

A problem with "making sure that no references exist any more" are Qt's 
metaobjects. These are created for each object-type that is derived from 
QObject but never destroyed by Qt.  meta-object unloading takes care that the 
meta-objects that belong to a certain library are destroyed before the 
library unloads.

Now to your questions:
a) The desire to unload DSO's. Unloading DSOs is done by e.g. konqueror and 
kwin. Konqueror loads parts as DSO and unloads them after some time when they 
aren't used any more. Kwin loads styles as DSO: when you change styles the 
DSO for the old style gets unloaded. This is unrelated to kdeinit. kdeinit 
loads applications as DSO but never unloads them.

b) Yes there is some overhead. All meta-objects created by the application 
need to be destroyed.

c) When you make a part or any other DSO that can be unloaded you should be 
aware of this problem. I don't know if you need to take any special actions. 
(You probably need to use the KDE build environment)

d) when you create a DSO that can be unloaded you will need meta-unloading.
Typically that means all parts and all plugins need it.

I assume that Michael will provide some more details.

Cheers,
Waldo
-- 
Make way, KDE/Linux is coming to a desktop near you!

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