On quarta-feira, 6 de fevereiro de 2013 22.54.45, Olivier Goffart wrote: > > factors. Namely: > > - wakeUp() is only called from qcoreapplication.cpp with the event queue > > > > mutex locked > > wakeUp is called from many places, and without the lock.
It's called from: - QCoreApplication::postEvent (locked) - QCoreApplicationPrivate::sendPostedEvents (locked) - QEventDispatcherUNIX::interrupt (called only from QEventLoop::exit) - QEventLoop::wakeUp - QObjectPrivate::setThreadData_helper (locked) - QWindowSystemInterfacePrivate::handleWindowSystemEvent (has a lock) Both QEventLoop::exit and QEventLoop::wakeUp do not need a lock, since they aren't changing the event queue. In QWindowSystemInterfacePrivate::handleWindowSystemEvent, the event queue is locked, but the lock is dropped before calling wakeUp. > It seems to be called from QCoreApplicationPrivate::sendPostedEvents with > the mutex locked, but that is a bug. We should unlock that mutex before > calling wakeUp, as wakeUp is user code and should not be called with the > mutex hold. That is true, but I'd argue that anyone implementing an event dispatcher is expert enough to deal with those issues. I'd just document that the function may be called with locked mutexes. Still, this is not a factor in the analysis. The next two guarantees are the important ones: > > - it's only called *after* the event queue has been modified in postEvent > > - processThreadWakeUp is only called *before* the event queue is > > inspected > Maybe there are other events? integration with a non-Qt event loop? That's what I said about the problem lying elsewhere. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
