[Development] Qt 5 types under consideration for deprecation / removal in Qt 6

Thiago Macieira thiago.macieira at intel.com
Thu May 30 20:35:38 CEST 2019


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





More information about the Development mailing list