[Interest] QProcess::waitForStarted() returns false after timeout, then what?

[Thiago Macieira]

On sábado, 11 de março de 2017 06:30:44 PST René J. V. Bertin wrote:
> Hello,
> 
> As far as I understand one doesn't have to call QProcess::waitForStarted()
> after QProcess::start(); process will start (or not) regardless of whether
> that method is called. Correct?

Correct. The starting is asynchronous and is happening in the background. It 
will also be made certain if you call any of the other waitFor functions.

> If so, what exactly does it mean if waitForStarted(x) returns false because
> of a timeout error? Does that mean the process could still end up being
> ready, i.e. could one do something like this?
> 
> job->start();
> if (!job->waitForStarted(10) && job->error() == QProcess::Timedout)
>     qWarning() << "this isn't instantaneous";
> if (!job->waitForStarted(600) && job->error() == QProcess::Timedout)
>     qWarning() << "maybe get some coffee";
> if (!job->waitForStarted(aVeryLongTime) && job->error() ==
> QProcess::Timedout) qCritical() << "better call the underTaker!";

It means one of:
a) your system is swapping so hard that everything takes 1000x more than it 
should (like the Qt CI system)
b) there's a bug and the process has started

> Or should any false return from waitForStarted() be taken as a definitive
> error that won't be recovered from?

Is the state QProcess::NotRunning or QProcess::Starting ? From reading the 
source code in qprocess_unix.cpp, the error QProcess::Timedout can only happen 
if poll(2) really did time out.

> FWIW I have already seen crashes occur when a timeout error is handled as a
> hard error (emitResult() called which apparently leads to deleting the
> QProcess instance without disconnecting its slots first).


-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center