move QCoreApplication::addLibraryPath call from KApplication to KComponentData

Thiago Macieira thiago at kde.org
Wed Nov 12 18:58:16 GMT 2008


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.

That's what a function-local static does in gcc:

	static bool initialised = lazyInit();

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

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
  Senior Software Engineer - Nokia, Qt Software
  Qt Software is hiring - ask me
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
-------------- 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/5c86588c/attachment.sig>


More information about the kde-core-devel mailing list