[Interest] BRe: can the QRegExpEngine cache acces objects belonging to an unloaded library during global destruction?
thiago.macieira at intel.com
Tue Jan 30 23:00:00 CET 2018
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-
> 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
More information about the Interest