summaryrefslogtreecommitdiffstats
path: root/src/libs/installer/adminauthorization_x11.cpp
diff options
context:
space:
mode:
authorFrerich Raabe <raabe@froglogic.com>2015-11-20 23:33:10 +0100
committerKarsten Heimrich <karsten.heimrich@theqtcompany.com>2015-12-08 13:07:10 +0000
commitd10e1605fb9f5e5fde452a148a7a89521f738571 (patch)
treee80ff526c560dfe6448d234fd9b185b1deee63d8 /src/libs/installer/adminauthorization_x11.cpp
parentff5a4a699b3c8026028ccdc2b602e9a03f803461 (diff)
Let ElevatedExecuteOperation delete its RemoteObject earlier
After running the process, ElevatedExecuteOperation would delete the QProcessWrapper object via deleteLater(). However, this would cause lingering remote connections: Operations are executed threaded via QtConcurrent::run(). The QtConcurrent threads don't run an event loop, so calling QProcessWrapper::deleteLater() would cause the object to get deleted once the thread finished. However, QtConcurrent uses a thread pool, so it may happen that the remote object is never deleted at all. Let's fix this by deleting the object right away. It should be safe no matter which thread runs the operation: 1. If it's the UI thread, the nested event loop will synchronize, i.e. the QEventLoop:exec() call only returns once the process finished. 2. If it's a non-UI thread, the code synchronizes via QProcessWrapper::waitForFinished(). In either case, the process will be finished by the time we get to the end of the function, so I think it's safe to just delete the object right away (and hence close the remote connection). Let's also add an assert to document our assumption. Change-Id: Ieb9970ff6452d404924824ece2a0a6e79552b0b3 Reviewed-by: Karsten Heimrich <karsten.heimrich@theqtcompany.com>
Diffstat (limited to 'src/libs/installer/adminauthorization_x11.cpp')
0 files changed, 0 insertions, 0 deletions