[Interest] BRe: can the QRegExpEngine cache acces objects belonging to an unloaded library during global destruction?

[Thiago Macieira]

On terça-feira, 30 de janeiro de 2018 13:51:55 PST René J. V. Bertin wrote:
> Apparently moc doesn't really know how to handle `QCache<QRegExpEngineKey,
> QRegExpEngine>` as the primary class signature. I hope that the difference
> in primary parent class between QT_BOOTSTRAPPED and normal mode won't lead
> to conflicts?

It's not that it doesn't know. It doesn't want to: QObject must always be the 
first parent (directly or indirectly).

There can't be conflicts because bootstrapped code is never mixed with non-
bootstrapped.

> Something else: is there a point to using QBasicMutex? I understand it's
> supposed to be faster, but QMutexLocker doesn't have a ctor for the class so
> it probably gets promoted to a QMutex. Don't you lose the performance
> advantage that way, and in addition pay for the conversion?

QBasicMutex is POD, unlike QMutex, so it's always statically initialised 
(except with buggy compilers, like MSVC 2017). QMutex requires a constructor 
to be run before you can use it, which could lead to use before the 
construction if some other dynamic initialiser called into this code. It 
shouldn't lead to any visible consequences because QMutex's constructor will 
fill it with zeroes, but it's UB.

You do lose a bit in performance if you call QMutex::lock() on a QBasicMutex: 
it makes an out-of-line call, instead of inlining the test-and-set. If not too 
hard, call .lock() and .unlock() directly.

Technically,  it's also UB to call QMutex::lock() on an object that isn't a 
QMutex. But we get away with it.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center