Can Q_GLOBAL_STATIC replace KStaticDelete ?

[Thiago Macieira]

Matthias Kretz wrote:
>The problem is that as soon as you keep any KDE object as a member of a
> static object you have to be sure it's not going to need a KInstance
> object on destruction. Do you know whether you're allowed to keep a
> KDirWatch object? Would you have known that keeping a dirty KConfig
> object until destruction will crash your program on exit?

This indicates that the problem is elsewhere. KInstance should be 
refcounted by the number of objects that reference it. It should only be 
deleted when that refcount drops to zero.

And since we can use QAtomic, we get a thread-safe refcounting mechanism.

>I think the semantics are clear with the following explanation (please
> add to it if you disagree):

They are unclear if we have K_GLOBAL_STATIC and Q_GLOBAL_STATIC. Having 
two is a problem.

I also oppose using the KInstance/QCoreApplication destruction as a 
mechanism, because it makes the global static creation that much slower 
(we need a mutex to be locked). But I'll accept the majority's needs.

But I formally oppose having both macros if they don't have the same 
semantics.

>The static object will be destructed by one of the following events
> (whichever comes first):
>- lib unload/exit
>- QCoreApplication destruction
>- global KInstance destruction
>
>The destruction order is the reverse of the construction order.

-- 
  Thiago Macieira  -  thiago (AT) macieira.info - thiago (AT) kde.org
    PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20070118/2c5effc9/attachment.sig>