[Development] bool QProcess::waitForFinished() Race Condition?

[d3fault]

On Wed, Sep 26, 2012 at 12:40 AM, André Somers <andre at familiesomers.nl> wrote:
> Op 26-9-2012 9:32, d3fault schreef:
>> I don't have a git clone and gerrit set up atm otherwise I'd submit
>> it. Can someone else do it for me?
> Well, this sounds like a fine time to get such a setup then?
>> And another semi-OT question relating to documentation: how are we
>> synchronizing wiki edits of the documentation with the git copies?
>> Seeing as the documentation lives in the .cpp files, automatic
>> synchronization sounds... uhhh... difficult.
> Simple: it is not. That is unfortunate, since there is valuable content
> in the docnotes (I assume that's what you mean with 'wiki edits of the
> documentation').
>

I need to lay off the crack. I must have hallucinated "edit" buttons
on the docs on qt-project.org/docs/ sometime in the past (or maybe it
was the nokia.com days). I thought qdoc (with a flag or similar tool)
was populating a wiki database with every release or something. But
yes, the docnotes are important too!

re: Below. tl;dr: clarifications in docs between QProcess and
underlying process, especially with respect to being finished.
And now I'm wondering if there are still scenarios where users might
get confused when using waitForFinished(). When using QProcess without
an event loop, wouldn't wait for finished always return true even if
the expected result is false (that it already finished)?

Scenario:

...programming without an event loop (lol)...

QProcess proc;
proc.start(aSmallAndFastBinaryAgain); // /bin/echo test , for example
//lots of other lines here, taking lots of time. maybe modal dialogs etc etc
bool finished = proc.waitForFinished();
//they would expect it to be false after reading the documentation and
getting confused between QProcess and the underlying process
//since we aren't using an event loop, QProcess never has the chance
to mark itself as finished. A user might think that since so much
stuff has happened (modal dialogs especially) in between that it would
be improbable that the process had NOT finished. They would be wrong
because QProcess never had the chance to update itself as being
finished (no event loop).

Proposed solutions: bool isFinished() which checks the underlying
process without needing an event loop
Or: A start/waitForFinished stack of sorts (haven't thought this
design through, see below) so that for every start(), a subsequent
call to waitForFinished() will always return true (but only once --
and obviously I'm ignoring the error cases where it should return
false)... regardless of if it is called with an event loop or not.
Would probably break existing code however :-/ (if using an event loop
and you give control back to the event loop so QProcess can mark
itself finished, a later call to waitForFinished returns false. After
this fix it would return true and thus break existing code).

I don't care too much about this because I am not programming without
an event loop... but I thought it was at least worth mentioning. This
is probably a waste of an email but maybe someone will read and
benefit from it years from now.

d3fault