summaryrefslogtreecommitdiffstats
path: root/tests/arthur/data/qps
diff options
context:
space:
mode:
authorShane Kearns <shane.kearns@accenture.com>2011-05-04 12:02:57 (GMT)
committerShane Kearns <shane.kearns@accenture.com>2011-05-04 12:19:24 (GMT)
commit5f241ec1426447380b1e938ac7888fb16cde94f8 (patch)
tree73908acf04908598eb8953930ba8af7794e7bfb3 /tests/arthur/data/qps
parentae128aef03d246c9f89bed015092b1c5a925bcbc (diff)
downloadQt-5f241ec1426447380b1e938ac7888fb16cde94f8.zip
Qt-5f241ec1426447380b1e938ac7888fb16cde94f8.tar.gz
Qt-5f241ec1426447380b1e938ac7888fb16cde94f8.tar.bz2
Fix QNetworkConfigurationManager usage outside main thread first
QNetworkConfigurationManager creates the engines loaded from plugins as objects in the main thread. If a QNetworkConfigurationManager instance is created in a worker thread without any instance previously existing in the main thread, then it is uninitialised until the main thread has run. This causes allConfigurations() to return an empty list if called immediately after instantiation, for example. This fix initialises the plugins using blocking queued connections, which causes the worker thread to block until the initialisation function has been called in the context of the main thread. Deadlock is possible if the main thread is for some reason waiting on the worker thread, but it will not deadlock on QNetworkConfigurationManager's mutex. If this is a problem for an application, it should use QNetworkConfigurationManager from the main thread first to preload the plugins. Task-number: QTBUG-18795 Task-number: QTBUG-18799 Reviewed-by: Cristiano Di Flora
Diffstat (limited to 'tests/arthur/data/qps')
0 files changed, 0 insertions, 0 deletions