summaryrefslogtreecommitdiffstats
path: root/doc/src/snippets/code/src_gui_kernel_qlayout.cpp
diff options
context:
space:
mode:
authoraxis <qt-info@nokia.com>2010-07-12 17:45:54 (GMT)
committerToby Tomkins <toby.tomkins@nokia.com>2010-07-27 07:58:32 (GMT)
commit9f60f8f1497b30962c13b2f61c71ee087bc58004 (patch)
tree522d4aed22eefa163876fe8b8823b5860b00f79b /doc/src/snippets/code/src_gui_kernel_qlayout.cpp
parented31fe5336f80ecbd025e75ba19308a881eb820d (diff)
downloadQt-9f60f8f1497b30962c13b2f61c71ee087bc58004.zip
Qt-9f60f8f1497b30962c13b2f61c71ee087bc58004.tar.gz
Qt-9f60f8f1497b30962c13b2f61c71ee087bc58004.tar.bz2
Fixed a network hanging bug on Symbian.
The problem happened because of a race condition in the way Qt cancelled the select call from Open C. Under high network loads, a network request could come in, causing the select call to end. Afterwards, the pipe normally used to cancel the select call would be emptied (although it was already empty). If a context switch happened after the pipe was emptied, but before the lock was released in waitCond.wait(), the main thread could try to grab the lock and write to the pipe because it was unsuccessful. This would in turn cause the next call to select to terminate immediately, and without work to do, the select thread would go straight down to waitCond.wait() and get stuck there. Fixed by moving the pipe draining loop from the select thread to the main thread, right after the lock grab. This guarantees that the select thread is empty when returning to the select call. Task: QT-3358 AutoTest: Passed RevBy: Markus Goetz (cherry picked from commit 61daa2f419696881ccdbc1cde2dc197eaf028ff6)
Diffstat (limited to 'doc/src/snippets/code/src_gui_kernel_qlayout.cpp')
0 files changed, 0 insertions, 0 deletions