On Wednesday, 29 May 2019 08:13:51 PDT Olivier Goffart wrote: > 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)
NAK on using a global. This should be in a TLS object. I wish we could use thread_local on non-POD objects. But we'd need to drop MinGW compatibility if we did that. Can we? > > === 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) Agreed. The reason we kept them out-of-line was for the ability to use Transactional Memory when it became widely available. But after 5 years after the Haswell architecture came out, it's still not widely available -- it's only present in Intel processors with vPro, which are usually servers or high- end desktops. That said, we should have an out-of-line fallback for all cases, so TSAN and DRD work. The other problem is: > > === QWaitCondition -> std::condition_variable(_any) === > > Yes. Can't change QWaitCondition without changing QMutex. It's all or nothing. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
