K_GLOBAL_STATIC

[Dan Meltzer]

On Tue, Aug 26, 2008 at 8:50 AM, Dan Meltzer
<parallelgrapefruit at gmail.com> wrote:
> 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.

... And in addition, we still use The::instance() to return the
pointer, K_GLOBAL_STATIC just creates the singleton for us.
>
> 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
>>
>