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@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@qt-project.org > https://lists.qt-project.org/listinfo/development _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
