move QCoreApplication::addLibraryPath call from KApplication to KComponentData

[Olivier Goffart]

Le lundi 10 novembre 2008, Matthias Kretz a écrit :
> On Monday 10 November 2008 12:07:59 Thiago Macieira wrote:
> > On Monday 10 November 2008 10:05:30 Matthias Kretz wrote:
> > > Hi,
> > >
> > > please review the attached patch. It makes the first KCD ensure that Qt
> > > knows about KDE's Qt plugin paths. This is necessary for non-KDE
> > > sessions where a KDE application that is not using KApplication is
> > > started.
> >
> > That means any non-KDE Qt application that loads a KDE plugin (such as
> > Oxygen) will get this code run. I don't know if this was your intention,
> > but I felt I needed to point out.
>
> Yes, that was my intention. And BTW if a Qt-only app manages to load Oxygen
> then it already has the KDE plugin path in its libraryPath.
>
> > Also, the initialisation the way you did it with QBasicAtomicInt isn't
> > thread- safe. You may as well use a simple boolean.
>
> why? I thought
>
> 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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20081112/2a8b8098/attachment.sig>