diff options
author | Shane Kearns <shane.kearns@accenture.com> | 2011-06-01 15:35:43 (GMT) |
---|---|---|
committer | Shane Kearns <shane.kearns@accenture.com> | 2011-06-13 11:37:51 (GMT) |
commit | 5f879c55e531165cc2569b03c3796d0f33d0a0b7 (patch) | |
tree | 892a26d3783e9cdaedc5eec5a5e13475c07cb08d /src/qbase.pri | |
parent | efba403423db53ed480bd88be4dcd650f8ae831a (diff) | |
download | Qt-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