diff options
author | Frerich Raabe <raabe@froglogic.com> | 2015-11-20 23:33:10 +0100 |
---|---|---|
committer | Karsten Heimrich <karsten.heimrich@theqtcompany.com> | 2015-12-08 13:07:10 +0000 |
commit | d10e1605fb9f5e5fde452a148a7a89521f738571 (patch) | |
tree | e80ff526c560dfe6448d234fd9b185b1deee63d8 /src/libs/installer/adminauthorization_x11.cpp | |
parent | ff5a4a699b3c8026028ccdc2b602e9a03f803461 (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