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

Philippe philwave at gmail.com
Fri Aug 23 11:04:07 CEST 2019


With the Windows implementation, there is indeed a mutex to protect an
internal list of waiters.

This is not a problem in itself, because std::condition_variable
probably does the same...

However, a problem with QWaitCondition that forced me to switch to std::condition_variable
is the following one:

calling QWaitCondition::wait may cause new() to be called, precisely to
update the waiter list.
And in my case, calling new() at any stage was forbidden by the
specification. An the MSVC implementation does not call new/malloc.

This could somehow be solved by using QVarLengthArray I guess.

Philippe

On Fri, 23 Aug 2019 10:31:20 +0200
"Mutz, Marc via Development" <development at qt-project.org> wrote:

> On 2019-05-29 12:53, Mutz, Marc via Development wrote:
> > === QWaitCondition -> std::condition_variable(_any) ===
> > 
> > Plumbing that std::condition_variable can do better.
> 
> So, I've looked at QWaitCondition because I had a need to call wait() 
> with a QBasicMutex instead of a QMutex, and that doesn't exist, yet. I 
> was surprised about what I saw, so I have to ask:
> 
> Do I understand it correctly that the implementation of QWaitCondition 
> has _another_ mutex inside?! So, two mutexes? The one users pass in and 
> then the one that QWaitCondition uses internally, because it's 
> pthread_cond and that needs pthread_mutex?
> 
> If that's the case, shouldn't we run, not walk, to replace our internal 
> uses with std::mutex + std::condition_variable to have only one mutex?
> 
> Thanks,
> Marc
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> https://lists.qt-project.org/listinfo/development





More information about the Development mailing list