move QCoreApplication::addLibraryPath call from KApplication to KComponentData

[Matthias Kretz]

On Wednesday 12 November 2008 19:58:16 Thiago Macieira wrote:
> On Wednesday 12 November 2008 19:46:25 Matthias Kretz wrote:
> > This affects global data and therefore you can construct a race scenario.
> > But that race is about a thread using the libraryPath information before
> > the KDE paths got added. I see no way to avoid this race.
> >
> > And I didn't try to avoid this race. I used the atomic int in order to
> > ensure that exactly one thread adds the KDE plugin paths as early as
> > possible -- nothing more.
>
> You can use a mutex to ensure that only one initialisation happens and, if
> any other threads enter that code path, they will wait for the
> initialisation to finish.

Right, but I didn't want to introduce a global mutex. And, really, I don't 
think it's worth to make this more heavyweight than it already is with an 
atomic int (an int should already be enough since KCD isn't threadsafe 
anyway).

> That's what a function-local static does in gcc:
>
> 	static bool initialised = lazyInit();

in default gcc4. But it's not portable... which is why we added -fno-
threadsafe-statics

> Our K_GLOBAL_STATIC does not ensure execution only once. That's where
> Q_ONCE comes in.



-- 
________________________________________________________
Matthias Kretz (Germany)                            <><
http://Vir.homelinux.org/