diff options
author | axis <qt-info@nokia.com> | 2010-07-12 17:45:54 (GMT) |
---|---|---|
committer | axis <qt-info@nokia.com> | 2010-07-13 13:51:35 (GMT) |
commit | 61daa2f419696881ccdbc1cde2dc197eaf028ff6 (patch) | |
tree | 6bf5d532ca8b07bf83e68a179eca387a5478c618 /doc/src/snippets/sqldatabase/sqldatabase.pro | |
parent | c042003a831ace1ffe4cc399668293200ffe829f (diff) | |
download | Qt-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