From fc14f5861e18d2ebc8014bfd750a8c82cf166392 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 (cherry picked from commit fc260f7ce9c139da93e005b2b51ef37c4d23998d) --- 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 e86efb2..2717780 100644 --- a/src/corelib/kernel/qeventdispatcher_symbian.cpp +++ b/src/corelib/kernel/qeventdispatcher_symbian.cpp @@ -481,7 +481,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