On 29.05.19 12:53, Mutz, Marc via Development wrote:
== MT plumbing ==
Let's make use of the std facilities to enable checkers such as TSAN to work
without hacks. It's not Qt's business to reimplement threading primitives.
Normally, checkers such as TSAN work out of the box.
But they kind of require Qt to be build with TSAN.
Probably need to keep some stuff around, like QThread, because of the
interaction with event processing, but before we add a lot of time making the
following classes play nice with the std, let's perspectively remove them:
I think we could get rid of QThread and get along with std::thread and
std::thread::id
We would have to keep a std::unordered_map<std::thread::id, QThreadData>, but
that might be a bit difficult. (What happens if we do
QObject::moveToThread(std::thread::id), and thread was already finished.
We can mandate that an the thread has a Qt eventloop, so we can use TLS
destructor to clean the map. But if we still access the thread handle after the
thread terminate, we have a problem)
=== QAtomic -> std::atomic ===
I agree.
=== QMutex / QReadWriteLock -> std::*mutex* ===
The implementation of QMutex, and especially QReadWrtieLock is much more
efficient that one of most standard library.
See https://woboq.com/blog/qreadwritelock-gets-faster-in-qt57.html
QMutex::lock and QMutex::unlock should be made inline, and then there should
be less problems with TSAN (I assume the problem is that TSAN does not "see"
the atomic operation when a Qt user uses QMutex and Qt itself was not compiled
with TSAN, and this is what you refer as work without hacks)
=== QMutexLocker -> std::unique_lock ===
1:1 replacement in the vast majority of cases. unique_lock has a lot more
features (movable, adopting a locked mutex, not tied to any particular mutex
class, ...)
Yes, with C++17 automatic template deduction, it is the same.
=== QWaitCondition -> std::condition_variable(_any) ===
Yes.
== QQueue / QStack -> std::queue, std::stack ==
== QSharedPointer / QWeakPointer -> std::shared_ptr/weak_ptr ==
== QSet / QHash -> std::unordered_set/map ==
== QMap -> std::map ==
Probably a good idea to get rid of that.
Could be kept as a third party optional library in the "Done" state, for those
user who like the API so much better. But it should be part of the Qt API.
--
Olivier
Woboq - Qt services and support - https://woboq.com - https://code.woboq.org
_______________________________________________
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
