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

List:       kde-core-devel
Subject:    Re: RFC: Proper destruction of static data?
From:       Waldo Bastian <bastian () kde ! org>
Date:       2000-06-27 22:08:54
[Download RAW message or body]

On Tue, 27 Jun 2000, Michael Matz wrote:
> First: Of what "static" you are talking about? Static member variables,
> where static simply means, that there is only one copy of that member for
> all instances? Or static variables, where static additionally means, that
> that variable is file local, meaning it can't be seen from outside that
> file.
[snip]
> Even nastier are static vars declared local to a function, as in "int
> a(){static i=0; if(!i) i=1; return i;}". If here "i" would be a pointer to
> object, there is absolutely no chance to destruct "i" from the outside
> unless a reference to that object i is pointing to also is collected on
> some other place. But mostly this is no real problem, as when its
> constructed with new, memory is allocated on the heap, and even on
> unloading that DSO, the object itself remains valid.

We are talking about static data as class member and static data inside 
functions. Most crashes can be prevented by, instead of using static classes 
, static pointers initialized to 0. 

Although this approach works it fails to destruct classes when the library 
gets unloaded. This is bad because it might leave references to objects 
around with corrupt vtables and the memory used by these objects is never 
returned.

> OK, that cleanup function would move the problem of destruction to a
> central place (that function) per library. Why should that solve the above
> mentioned crashes? The following talks about the problem of calling a
> function at DSO load/unload time, but without knowing how that should help
> with those crashes.

> That moving to a single place is good, but does not solve the problem, of
> by whom it should get called. Think of the following situation:
> DSO2: DSO0 DSO1
> App: DSO0
> and App dlopens DSO2.

Sounds like kword :-)

> One first could think to change libltdl a bit, and if ever ltdlclose() is
> called that library finalizer is called by hand. But that would forget the
> libraries implicitely loaded by loading DSO2 (that of DSO1 in this case).
>
> That is basically the situation also with metaunloading. I have one
> function per DSO, which should get called on DSO unload.

The problems with metaunloading is basically the same. (Getting rid of static 
objects)

>    OK, you may say, but that solves the problems of static objects with
>    static objects. But I want to use only _one_ static object for the
>    whole DSO and mainly as a vehicle to call a function at
>    loading/unloading time.

Yes, I support that. With one static object we know where to look. If static 
objects are used all over the place it becomes very hard.

>    Anyway, this is the most portable way I could come up with.
>
> Basically there is already some work in am_edit and kunload.h to construct
> a function which gets called exactly at unload time (the metaunload
> stuff). Its using 3). It could be extended to call other functions.

[Snip]

> On could even invent a method to annotate functions which should be called
> on unload or load for additional work, but that is also possible now with
> static object and a small helper class. Don't know what would be better.
> (But this would be a mechanism for the developer to ensure a particular
> order when destructing those pointers, so may be, it would make sense.)

Sounds good.

> Hmm, now I'm a little bit confused, about where we stand ;) Do you have
> already such KSTATIC'ified sources, one could use as a base for am_edit
> hackery, preferably with some crashes, which you hope to solve by all
> that?

No. It's a purely theoretic excercise up till now. (Well, kword/kspread 
crashed due to static objects, but there wasn't a strong need for them to be
static.)

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]