From fc260f7ce9c139da93e005b2b51ef37c4d23998d Mon Sep 17 00:00:00 2001 From: axis Date: Mon, 12 Jul 2010 20:06:14 +0200 Subject: Fixed a possible hanging bug in the Symbian networking. I haven't seen the bug happening in practice, but I decided to be safe rather than sorry. The rationale is that if a network request comes in, the select thread will signal the active object in the main thread, remove the socket from the set of monitored sockets, and then go to sleep in the waitCond.wait() call, waiting for reactivation by the QSelectMutexGrabber. However, in QEventDispatcherSymbian::socketFired(), if the event causes the socket to be deleted, reactivateSocketNotifier will never be called, and therefore the wait condition will never be terminated. Fixed by only entering the wait condition if a grabber has already written to the pipe, signalling that it wants the lock. AutoTest: Passed RevBy: Markus Goetz --- src/corelib/kernel/qeventdispatcher_symbian.cpp | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/corelib/kernel/qeventdispatcher_symbian.cpp b/src/corelib/kernel/qeventdispatcher_symbian.cpp index 7da1b69..1b0c31b 100644 --- a/src/corelib/kernel/qeventdispatcher_symbian.cpp +++ b/src/corelib/kernel/qeventdispatcher_symbian.cpp @@ -480,7 +480,8 @@ void QSelectThread::run() updateActivatedNotifiers(QSocketNotifier::Write, &writefds); } - m_waitCond.wait(&m_mutex); + if (FD_ISSET(m_pipeEnds[0], &readfds)) + m_waitCond.wait(&m_mutex); } m_mutex.unlock(); -- cgit v0.12