Can Q_GLOBAL_STATIC replace KStaticDelete ?

Thiago Macieira thiago at
Thu Jan 18 11:13:29 GMT 2007

Simon Hausmann wrote:
>I just spoke with Brad and the bad news is: Do not use Q_GLOBAL_STATIC.
> It is going to change in the future. Also do /not/ use the
> q_atomic_with_underscore functions. They are going to change as well.
> Q(Basic)AtomicPointer is good to use though. (reasonably safe ;-)

We still need Q_GLOBAL_STATIC. Like I said in the original email in the 
other thread, there is simply NO way of accomplishing a thread-safe 
static object creation without it, global or not, unless we start 
requiring that KApplication or KInstance be already created. And we will 
need that for any and all singletons.

We cannot rely on a constructor function to create a global QMutex for us. 
We cannot rely on a constructor function at all, since any of our 
libraries may have been loaded as a result of plugin loading -- which may 
skip constructors in some systems.

We cannot also rely on the C++ compiler having guards against reentrancy 
in static objects. I remember reading the C++ spec: it leaves 
specifically undefined the behaviour of reentrancy. This includes 
thread-safety. (g++ 4.x is fine, though)

In all, we need Q_GLOBAL_STATIC or we'll be forced to implement it with 
pthread or QBasicAtomicPointer for KDE. Any chance we can get it for Qt 

I'd rather not copy qglobal.h, do a s/Q/K/g and change 
q_atomic_test_and_set_ptr for the QBasicAtomicPointer that simply calls 

One other thing: Q(Basic)Atomic(Pointer) uses the 
q_atomic_with_underscores functions inlinedly.

  Thiago Macieira  -  thiago (AT) - thiago (AT)
    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: <>

More information about the kde-core-devel mailing list