summaryrefslogtreecommitdiffstats
path: root/src/qbase.pri
diff options
context:
space:
mode:
authorShane Kearns <shane.kearns@accenture.com>2011-06-01 15:35:43 (GMT)
committerShane Kearns <shane.kearns@accenture.com>2011-06-13 11:37:51 (GMT)
commit5f879c55e531165cc2569b03c3796d0f33d0a0b7 (patch)
tree892a26d3783e9cdaedc5eec5a5e13475c07cb08d /src/qbase.pri
parentefba403423db53ed480bd88be4dcd650f8ae831a (diff)
downloadQt-5f879c55e531165cc2569b03c3796d0f33d0a0b7.zip
Qt-5f879c55e531165cc2569b03c3796d0f33d0a0b7.tar.gz
Qt-5f879c55e531165cc2569b03c3796d0f33d0a0b7.tar.bz2
bearer: run the bearer engines in their own worker thread
The original architecture of the QtNetwork bearer support hosted the engines in the application's main thread, but this causes some problems. If the QNetworkConfigurationManager is constructed in a worker thread, then it is populated asynchronously without any notification when it is done (the app gets incomplete or missing results) Fixing that by restoring the earlier behaviour of using blocking queued connections to wait for the lists to be populated caused a regression, as some applications deadlock because the main thread is waiting on the worker thread at this time. By introducing a dedicated worker thread for the bearer engines, QNetworkConfigurationManager can be safely constructed in any thread while using blocking queued connections internally. Task-number: QTBUG-18795 Reviewed-by: mread
Diffstat (limited to 'src/qbase.pri')
0 files changed, 0 insertions, 0 deletions