When reaping a process: do one call to terminate() and after
500 ms timeout (default) do one call to kill() if the process is
still running. When the process finishes, end reaping by
deleting the reaper and its process. Ensure that the state of
the process is NotRunning before deleting it.
Eliminate the need to process events in ProcessReaper's destructor.
This change removes the emergency counter, which could caused
issues when the process was still running and the emergency
conter was above 5. Before, we were forcefully deleting the
running process. Now we wait as long as it's needed for process
to finish.
Since the reaper was operating in the main thread before,
it could happen that ProcessReaper inside the process launcher
could have blocked the launcher's main thread considerably, when
emergency counter exceeded the value of 5 and the destructor
of QProcess was run in turn. In this case the process launcher couldn't
operate and couldn't handle other running processes. This could cause
that corresponding running QtcProcesses on Creator side
timed out. Moving the reaper to the separate thread eliminates
this issue.
Change-Id: Id78953a2aec5cb08dc869621386b6a61a182e81c
Reviewed-by: hjk <hjk@qt.io>
Give process launcher a chance to finish its processes
gracefully before we finish process launcher's process in Creator.
Otherwise, when Creator's process reaper kills the process
launcher's process while the process launcher is still
reaping its processes, the process launcher may leave zombies.
Instantiate the ProcessReaper inside ProcessReaper::reap(),
otherwise its destructor won't run at all inside process launcher.
Reverts e45e16d904
Fixes: QTCREATORBUG-27118
Change-Id: I00290cda05538b5a7ecbeb08240d1e3772d43d62
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Utils::Internal::Reaper class is doing graceful termination of
process. It tries in a loop to first terminate() then kill()
the process and at the end delete the object.
Utils::ProcessReapder::reap should not kill the process directly,
and now that the function works with a QProcess, the special
handling of QtcProcess::terminat() of qtcreator_ctrlc_stub.exe
processes needs to be handled explicitly.
Amends ace765c199
Fixes: QTCREATORBUG-26612
Change-Id: Ia109ec0737a8c605a84e93b6ee3691d843ed5da8
Reviewed-by: David Schulz <david.schulz@qt.io>
Reviewed-by: hjk <hjk@qt.io>
Introduce Utils::Singleton class and
Utils::SingletonWithOptionalDependencies class template
that helps implementing singletons that depend on other
singletons. It's guaranteed that whenever singleton B depends
on singleton A, than A is always created before B is being
created, and that the order of destruction is always
opposite to the order of creation.
Dependencies of singleton are listed as template arguments
for SingletonWithOptionalDependencies class template.
The first argument of SingletonWithOptionalDependencies
class template is always a singleton class itself.
Prepare a common interface for all singleton subclasses:
SingletonSubClass *SingletonWithOptionalDependencies::instance();
Make instantiating singletons and its dependencies thread-safe.
Create singletons on demand (only if some code needs them).
It's not needed anymore to explicitly instantiate
all required singletons in tests.
Make it possible (and thread-safe) to instantiate ProcessReaper
and LauncherInterface singletons in non-main threads.
Make the following dependencies between existing singletons:
SshConnectionManager depends on:
-> LauncherInterface depends on:
-> ProcessReaper
Change-Id: Iefaacab561c2b3dcf07e7fafbb87339ea6a15278
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Reuse ProcessReaper inside process launcher.
Automatically reap all internal QProcesses of QtcProcess
(either direct child of QtcProcess in QProcessImpl
or indirectly inside process launcher).
Make ProcessReaper work again on QProcess instead of on
QtcProcess, so it may still be reused for non-QtcProcesses.
Change-Id: I950cac5cec28f17ae97fe474d6a4e48c01d6aaa2
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: hjk <hjk@qt.io>
