K_GLOBAL_STATIC

[Dan Meltzer]

On Tue, Aug 26, 2008 at 8:23 AM, Ian Monroe <ian at monroe.nu> wrote:
> On Tue, Aug 26, 2008 at 5:52 AM, Seb Ruiz <ruiz at kde.org> wrote:
>> 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.

I'm not completely familiar with this discussion, but I believe markey
ported a lot of the code _to_ K_GLOBAL_STATIC because having non-pod
static types is what caused the non-deterministitc destruction.  This
resulted in all the hangs on exit that plagued Amarok, and making them
K_GLOBAL_STATICS with the post routine was the way to fix it.  I would
really suggest that we don't change _anything_ like this until after
2.0, as this would be a bad time for regressions.

I also believe K_GLOBAL_STATIC is safe across library bounds or
something like that, that makes it better than just using static
instance variables.  I might be disremembering that though.

Dan,
>
> As long as your going towards determinism, you should have the
> The::class() only return a pointer - not create the class if it wasn't
> already. Then you can precisely decide where you want the construction
> of the class to happen.
>
> At least, its something to think about. Maybe a case-by-case thing.
>
> Ian
> _______________________________________________
> Amarok-devel mailing list
> Amarok-devel at kde.org
> https://mail.kde.org/mailman/listinfo/amarok-devel
>