Add a setter and getter for reaper timeout. This makes it
possible to customize the timeout for the reaper after which it
should call kill() when previous terminate() was unsuccessful.
This setting is also used for QtcProcess::stop().
Change-Id: I653a3ad107ae4173bb8254c85cfc07886bf6a9c6
Reviewed-by: hjk <hjk@qt.io>
This method works like close() with the difference that
after calling stop() we are still going to receive
signals from QtcProcess, especially done() signal.
This method isn't blocking, so a calling it is fast.
Just after calling this method QtcProcess is still
in the same state and done() signal should be delivered
asynchronously. It's safe to call waitForFinished() after
calling stop() with the desired timeout.
Calling stop() in a row with waitForFinished() is a good
substitute for stopProcess().
Change-Id: I1df55beb7f89c9b73203c9ba4bc276a4060600a5
Reviewed-by: hjk <hjk@qt.io>
More descriptive, and later implementable without full expansion.
Change-Id: Ic3b17ea0b07273f292827a7b63e7695b4bd1cf23
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Fix it also for general waitForSignal() implementation.
Amends fc2f3983bc
Task-number: QTCREATORBUG-27578
Change-Id: Ifb9ebbd5c3fa2c900bae924aefccb713983b1697
Reviewed-by: hjk <hjk@qt.io>
Make it behave more like QProcess::kill().
Before, when QtcProcess::kill() has been called,
the process launcher was putting the process into the
reaper and notified the QtcProcess that it was already killed,
while in fact it could still be alive for a while since it
was in reaper's hands. The current fix makes the behavior
similar to what QProcess does when calling kill(). So now,
in case of a call to kill() the process isn't put into the reaper yet,
so it has a chance to report back the finished signal when the
process was really stopped.
We still use the old behavior of putting the running process
into the reaper in case of a call to QtcProcess::close() and
when d'tor of QtcProcess was called. We don't report back the
confirmation about putting the process into the reaper, since
close() is always called from ProcessLauncherImpl d'tor, so
there is no one to receive this confirmation anyway.
Change-Id: I665e7c8fb1a391dda30c86389259961e715926d6
Reviewed-by: hjk <hjk@qt.io>
Round 2 - focus on sources.
For classes with initial in range [I-Z].
Try to keep the same separators between different kind of headers.
Change-Id: I8a7ab99bab8120ee72cda6433ee3dc6f260a4d76
Reviewed-by: hjk <hjk@qt.io>
Round 1 - focus on headers.
For classes with initial in range [P-R].
Try to keep the same separators between different kind of headers.
Change-Id: I01fb80b93164a7fe4c0bd2cd8f9e4f27523efefa
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
It's a result of a team work consisting of yellow triangle and me.
Change-Id: I8b4812766da70e0785ae71bf0cb71357379e2514
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
process_ctrlc_stub doesn't generate a Ctrl+C event sent via
GenerateConsoleCtrlEvent for the child process to terminate.
So the Debug restriction to workaround QTCREATORBUG-11995 is
no longer needed.
Change-Id: Iafc8b51bce17432c80b0be0c4084978abc1c909f
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: Orgad Shaneh <orgads@gmail.com>
... and drop QtcProcess::removeEnvironment()
This shifts the meaning of the unqualified QtcProcess::environment()
to always refer to (possibly remote) "main" process this QtcProcess
wraps. The controlEnvironment is now referring to secondary helper
processes (if any...) typically(?) running on the host system.
This helps to avoid local/remote distinctions in some places.
Change-Id: Ib7cd15dd226617484b5358acd7deaed29e751883
Reviewed-by: Jarek Kobus <jaroslaw.kobus@qt.io>
Currently, as a result of many refactorings, the QtcProcess
is designed so that if you want to customize the behavior
you should implement custom ProcessInterface subclass.
Adding virtual methods directly to QtcProcess caused tons of
unpredicted side effects and nasty bugs, which were hard to
track and hard to fix, as provided fixes were usually fixing
particular case while introducing regressions in not related
code paths.
Consider also aggregating QtcProcess object instead of
deriving from it when some additional methods are required.
This patch removes the last virtual methods from QtcProcess API
and makes the class final in order to prevent from adding
any new virtual methods to this class in the future.
This commit message should make it clear that having subclasses
of QtcProcess is not a desired design. It's a post-mortem
conclusion. So: don't derive from QtcProcess - we mean it!
Change-Id: I1e43ed45be326b366422fd7db6e05ba48ea5fb98
Reviewed-by: hjk <hjk@qt.io>
There is no need for special handling when running on remote.
Change-Id: If30245d2ece475cb72df2be4390210d6b8c0c1aa
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
When a QProcess is being started in a thread that doesn't have
event dispatcher installed, e.g. in a thread started with
std::async(), the process signals are emitted only from inside
QProcess::waitFor...() functions, but not emitted spontaneously.
This may cause issues when adding the running process into the
ProcessReaper, as the implementation of the latter relies on
signal emission and doesn't use blocking API of QProcess.
Currently there is one case like this: ProcessCreator::createProcess()
of clangsupport library.
Change-Id: I823a139b356f62fee9e0e5d6fc8326301c36b449
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Centralize some boiler plate and warn about best-guessed cases.
Keep the QByteArray based access as writeRaw()
Fixes: QTCREATORBUG-27445
Change-Id: I948d80fba78b36cf85cc73664175ab05eb7707d4
Reviewed-by: Orgad Shaneh <orgads@gmail.com>
Reviewed-by: Jarek Kobus <jaroslaw.kobus@qt.io>
Use ProcessInterface's setup data when handling
readyRead signals. In this way the user may still
change this setting, also when QtcProcess is running,
as a preparation for the next run. In this way this
works like all other QtcProcess mutators.
Change-Id: Ie80475e322162ce109fb95468ce858f9c98eefa9
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: hjk <hjk@qt.io>
Do not return false from QtcProces::waitForStarted if the process is
already running. This causes mayor issues on windows since QProcess
directly emits started and therefore switches to the running state after
calling QProcess::start.
Change-Id: I4604b08a59918d3df11c8a174b57e1e483e78a0d
Reviewed-by: Jarek Kobus <jaroslaw.kobus@qt.io>
Restored the process channel mode members to ProcessSetupData and
StartProcessPacket and forward to the QProcess created in
LaunchSocketHandler. LaunchSocketHandler now avoids reading from stderr
for merged channels since it's guaranteed to not be available.
This avoids asserts in Qt 6.3.0 and warnings in Qt 6.3.1 while
preserving the original output order when an application has a mix of
stdout and stderr output.
Change-Id: I9f4541932cf9d8638b38658a5efea9cb5f1798f3
Reviewed-by: Jarek Kobus <jaroslaw.kobus@qt.io>
This is fully controlled by QtcProcess itself, so provide
general implementation of state() inside QtcProcess.
Task-number: QTCREATORBUG-27358
Change-Id: Id6f0b771ed933f870b80d6856c6d94896f946516
Reviewed-by: hjk <hjk@qt.io>
Keep the setup data on stack instead on heap.
Task-number: QTCREATORBUG-27358
Change-Id: I0fffd525e2bd4f46533804e3b88fe5b330d02a91
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
It doesn't seem to be useful anymore.
Add some comments to the ProcessInterface API.
Move virtual interface into the private section
in order to not to use it directly from implementation.
Task-number: QTCREATORBUG-27358
Change-Id: Idd9fd39cf153832e6e44e125fbbd5c8236a2d930
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Implement it in general way inside QtcProcess instead.
Task-number: QTCREATORBUG-27358
Change-Id: Ibc4c9753c57cd73afcccb2991282ee459dc69780
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
And get rid of readyReadStandard[Output/Error]() signals.
Get rid of readAllStandard[Output/Error]() accessors, as
this data is passed with readyRead() signal.
Task-number: QTCREATORBUG-27358
Change-Id: I01341feba650e650761f97e90f83b6042c899251
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
And get rid of errorOccurred() and finished() signals.
Get rid of resultData() accessor, as this data is passed
with done() signal.
Task-number: QTCREATORBUG-27358
Change-Id: I677bbd174cceea6d8f5a989f961222c417992b60
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
ProcessLauncherImpl::terminate() was behaving the same as
ProcessLauncherImpl::kill() in case of process launcher
implementation - in both cases the launcher
immediately returned confirmation about receiving the
close request and was putting the corresponding
process into its reaper. However, the issue with this approach
is that we can't receive anymore any potential ready
read signal from the process being terminated after
a call to terminate().
The fix is to diverge the behavior of terminate()
and kill() of ProcessLauncherImpl. The behavior of kill()
remains the same, while terminate() just instructs the
process launcher to start termination without putting
the process into the reaper, yet.
Add a test that checks for any possible zombies.
We run the RecursiveBlockingProcess recursively. The most
nested process blocks. After a short wait we terminate
the outermost process. With this test we are trying to see
if terminating the middle process terminates also its
children and doesn't leave zombies.
Before we execute the test (and also by the end of this test)
we call Singleton::deleteAll() in order to ensure that reaping
of previously running processes has finished. We ensure the
number of running processtestapps is zero. Later, we ensure that
the leaf process was already started and the number of running
processtestapps equals the depth of recursion.
Fix apparent bug in getLocalProcessesUsingProc().
Change-Id: I7e2bc46ad5ca22f26620da86fbaf0fa00a7db3c3
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
This test introduced some additional private API to QtcProcess.
This makes refactorings of QtcProcess harder, as we need to
handle this artificial code working.
We have a real lineCallback() test instead which doesn't
employ this private API.
Change-Id: Idbc314210cecc2044e1ccc298e5d3e0a9747e811
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
It should be useful when reimplementing ProcessInterface.
It replaces 4 virtual methods with just 1.
Task-number: QTCREATORBUG-27358
Change-Id: I2dafbfbc25f8f016ff2aa19c1a176335a4a7498c
Reviewed-by: hjk <hjk@qt.io>
Guard that we don't delete the QtcProcess directly from
inside its handlers.
This helps in detecting wrong usage of QtcProcess.
Change-Id: Ia5b154b3e1f827d579910ebe81ae230fc797c377
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Introduce QtcProcess::done() signal. It's similar to
QtcProcess::finished() signal, but also emitted when
process failed to start (so after QProcess::FailedToStart
error occurred).
SshRemoteProcess::finished() signal was already behaving
like this. So, we remove special handling of
FailedToStart error in this class and connect all clients
of SshRemoteProcess to done() signal, instead of finished().
Task-number: QTCREATORBUG-27232
Change-Id: If4240e2172f3f706e812bca669a1d5b24bdc3285
Reviewed-by: hjk <hjk@qt.io>
It's internal method, not meant to be used outside.
It's only used in case of FailedToStart error.
Remove it also from ProcessInterface.
Leave it inside DefaultImpl and its subclasses only.
Remove m_errorString field from ProcessSetupData.
Change-Id: Ie605b95c2ff605ab1259045f1a5b16049207c1d3
Reviewed-by: hjk <hjk@qt.io>
I find it too confusing to have that inheritance only to enforce
similar interfaces.
Change-Id: I9da68ea59c04f709228e0874460e987115b30f56
Reviewed-by: Jarek Kobus <jaroslaw.kobus@qt.io>
Don't detect a call to QtcProcess::kill() from inside the
QtcProcess callback while awaiting inside QtcProcess::waitFor...().
That's not needed, since a call to kill() sends a stop message
to the process launcher, so we wait for confirmation
from process launcher instead. This may bring e.g. new
read data from the running process.
Fix a runBlockingStdOut() test so that when we write to the stdOut
from the running process we flush the unfinished line so that
it's not buffered inside the process.
Change-Id: I7944ac214d8cb9e10a71715a7ef8bfacab6df7c9
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
...instead of ensuring in many functions that m_setup isn't null.
This amends 36c49cd2ea and
solves the issue for other functions like processId(),
exitCode(), etc...
Amends 36c49cd2ea
Change-Id: I986f7b30e90e5825ae2bb57b4bc2aa14f56e401f
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: hjk <hjk@qt.io>
ProcessProxyInterface will be helpful when implementing
public subclasses of ProcessInterface, like
general ssh impl, linux specific impl, qnx specific, etc.
ProcessProxyInterface is sharing private data
between proxy and target.
Change-Id: I8350837bb5f770d6605b860b146604cba5e6b592
Reviewed-by: hjk <hjk@qt.io>
