K_GLOBAL_STATIC

[Maximilian Kossick]

I'd have to look it up again this weekend, but as far as I remember
destruction of static objects the way we defined them earlier happens
at destruction of the application, and therefore is totally out of our
control too (just like K_GLOBAL_STATICs without that qPostRoutine). If
I remember this correctly, replacing K_GLOBAL_STATIC with our previous
approach for singletons won't gain us anything.

The whole approach is flawed anyway, what we really need is state
management for amarok, i.e. there would be a single class that would
control the creation of essential services on startup, and control the
order of destruction on shutdown. This was actually proposed by Mirko
during last year's akademy, but I never got around to writing that
code (I haven't even finished designing it, although I still have a
couple of attempts lying around on my laptop back home). You could do
a couple of interesting things with that kind of state management
(e.g. threaded startup, easy power management), so if somebody wants
to implement that for 2.1 ...

Max

On 8/26/08, 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.
>
> 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
>