summaryrefslogtreecommitdiffstats
path: root/doc/src/snippets/sqldatabase/sqldatabase.pro
diff options
context:
space:
mode:
authoraxis <qt-info@nokia.com>2010-07-12 17:45:54 (GMT)
committeraxis <qt-info@nokia.com>2010-07-13 13:51:35 (GMT)
commit61daa2f419696881ccdbc1cde2dc197eaf028ff6 (patch)
tree6bf5d532ca8b07bf83e68a179eca387a5478c618 /doc/src/snippets/sqldatabase/sqldatabase.pro
parentc042003a831ace1ffe4cc399668293200ffe829f (diff)
downloadQt-61daa2f419696881ccdbc1cde2dc197eaf028ff6.zip
Qt-61daa2f419696881ccdbc1cde2dc197eaf028ff6.tar.gz
Qt-61daa2f419696881ccdbc1cde2dc197eaf028ff6.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
Diffstat (limited to 'doc/src/snippets/sqldatabase/sqldatabase.pro')
0 files changed, 0 insertions, 0 deletions