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