move QCoreApplication::addLibraryPath call from KApplication to KComponentData

[Matthias Kretz]

On Wednesday 12 November 2008 19:00:17 Olivier Goffart wrote:
> Le lundi 10 novembre 2008, Matthias Kretz a écrit :
> > QBasicAtomicInt flag = Q_BASIC_ATOMIC_INITIALIZER(0);
> >
> > void someFunction()
> > {
> >   if (flag.testAndSetOrdered(0, 1)) {
> >     // this is only reached once
> >   }
> > }
> >
> > If testAndSet is atomic (I don't even see the need for the memory
> > barrier) there's only one thread that can return true from the testAndSet
> > call...
>
> You are right but that's assuming no code actually relies on what's done
> inside this:
>
> The next code show an example of problem.
>
> void someFunction()
> {
>   static Foo bar;
>   if (flag.testAndSetOrdered(0, 1)) {
>      bar = lazyInit(); //done only once
>   }
>
>   use(bar);   //might be done before bar has been initialized
> }
>
>
> Now I don't have enough context to know if it is or not dangerous in your
> particular case.

the context is:
1. lazyInit gets called in the ctor if the flag is 0. Since the code in the 
ctor it's implicitly single threaded, there's no problem wrt. local data.

2. in lazyInit itself the KDE plugin paths are added to 
QCoreApplication::libraryPath if the flag is 1. I.e. the first thread to reach 
lazyInit (doesn't have to be the one where lazyInit was called from the ctor). 

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.

Most of the discussion is academic anyway since the mechanism is meant for KDE 
applications -- where KComponentData is normally instantiated before threads 
are created or the mainloop is executed.

Please tell me when you think I may commit.

Regards,
	Matthias

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