diff options
author | Kai Köhne <[email protected]> | 2025-05-27 15:21:19 +0200 |
---|---|---|
committer | Kai Köhne <[email protected]> | 2025-06-24 12:08:24 +0200 |
commit | 46b2a0c1b6de152fee37bfe0b39e3f2b11ba1b15 (patch) | |
tree | e7729859a2be9671b98db707a25e7bf3e7f79260 /examples/sql/sqlbrowser/main.cpp | |
parent | 127a0926dff31d9b98397511deb7320a3b6bcc00 (diff) |
The existing mutex in QCoreApplicationPrivate already protects
access to translation data while QCA::installTranslator(),
::removeTranslator() are running. Extend this to also protect the
altering methods in the QTranslator class itself. This makes sure
that the installed QTranslator objects can be safely altered via
QTranslator::load().
As loading translations might actually take a while, we don't want
to unnecessarily lock the mutex for QTranslator objects that are
_not_ registered. Instead, the patch introduces a
QCAPrivate::mutexLockerForTranslator()
method that returns a std::unique_lock<> object. If the QTranslator
is not registered, the mutex is instantly unlocked in the method.
If it is registered, the mutex is only unlocked after the scope of
the calling code is exited (so the end of QTranslator::load()).
Unfortunately, QWriteLocker does not support std::move semantics.
Therefore switch to a simple std::unique_lock/QMutex. This means that
QCoreApplication::translate() cannot be executed concurrently
from multiple threads anymore, but that is arguably not the
most common case, anyhow.
While at it, remove the QTranslatorList typedef.
Pick-to: 6.10
Task-number: QTBUG-137179
Change-Id: Id5c7abf0e7664058cb07cf76a0e9532533e37ad3
Reviewed-by: Thiago Macieira <[email protected]>
Diffstat (limited to 'examples/sql/sqlbrowser/main.cpp')
0 files changed, 0 insertions, 0 deletions