K_GLOBAL_STATIC

Seb Ruiz ruiz at kde.org
Tue Aug 26 12:52:39 CEST 2008


Hi devs,
Max, this one is specifically for you.

During Akademy we discussed the use of the K_GLOBAL_STATIC macro
throughout the Amarok codebase. We should all be aware of the previous
heated discussions as to whether we should/should not be using this
macro so extensively throughout our source.

For what it's worth, the advantages of using this macro are:
a) Awesome code style, which is what all of us crave and strive for to
the utmost. No messing around with Class::instance()->method() calls
b) We write 12 less characters

This would be really cool if weren't punished with one fatal flaw of
the macro, non deterministic destruction of K_GLOBAL_STATIC objects.
This is a major problem because during an Amarok shutdown we need to
guarantee the availability of static object instances for writing
config settings and shutting down services etc. Now of course, there
is a work around to this, which is to add and remove the object as a
qPostRoutine where relevant. Having to do this has more repercussions,
such as nullifying the cool code style (we need to add cryptic
methods) and, more importantly, we need to remember to add this code.
Without it, Amarok will have a much higher crashyness factor. Case in
point, we are still having occasional random corruptions on shutdown.

In summation, a few of us who discussed this at Akademy would like to
propose moving away from the K_GLOBAL_STATIC entirely, and back to our
trusted Class::instance() (or The::class() ) where we can reliably and
deterministically define the order of desctruction. There has already
been a volunteer to do the tedious dirty work.

-- 
Seb Ruiz

http://www.sebruiz.net/


More information about the Amarok-devel mailing list