diff options
author | Shane Kearns <shane.kearns@accenture.com> | 2011-05-04 12:02:57 (GMT) |
---|---|---|
committer | Shane Kearns <shane.kearns@accenture.com> | 2011-05-04 12:19:24 (GMT) |
commit | 5f241ec1426447380b1e938ac7888fb16cde94f8 (patch) | |
tree | 73908acf04908598eb8953930ba8af7794e7bfb3 /tests/arthur/data/qps | |
parent | ae128aef03d246c9f89bed015092b1c5a925bcbc (diff) | |
download | Qt-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