[Development] Qt5.15 deprecating & Qt6 removing QProcess::setupChildProcess

[Edward Welbourne]

Thiago Macieira (17 February 2020 20:35) wrote:
> Sorry, this just occurred to me. This is a request for 5.15 feature freeze
> exception.
> 
> Re: https://bugreports.qt.io/browse/QTBUG-17331

Closed: 30-07-2013 03:38, >9 years ago.

> Re: 97645478de3ceffce11f58eab140c4c775e48be5
> ("QProcess: use FFD_USE_FORK when the class is not QProcess itself")

Committed to 5.15, has not appeared in any release yet.
Modifies (only) corelib/io/qprocess_unix.cpp, only internal to
QProcessPrivate::startProcess(); no API change.

> The bug report is complaining that the use of fork() instead of
> vfork() on some systems with very low memory left (and no overcommit)
> can cause fork() to fail. The commit I pointed to is a workaround I
> had to add after adding pidfd support for when setupChildProcess() was
> overridden, due to differences in internal glibc locking differences
> between fork() and clone().
> 
> Note also that setupChildProcess() does not work on Windows, where
> there's no fork() [trust me, I spent a great deal of time researching
> this topic].  Instead, we have a callback with
> setCreateProcessArgumentsModifier(). It also didn't use to work on
> QNX, where we used posix_spawn(), though that's gone by now.
> 
> I don't think we can remove the ability to run user code in the child
> process.  But can we remove the virtual? Can we just have a callback
> like on Windows?

I take it that would involve an API change.
I see QProcess has differences in API between MS and Unix.
Reducing that inconsistency would be good.

We would presumably want to subsequently rationalise the MS and Unix
APIs to have a common form, instead of having naked MS types in the API
for one and something else for the other.  That would mean deprecating
the existing MS-specific API in favour of a cross-platform API at some
point.  Please estimate which versions of Qt the different stages of
that unification would happen in, given that you start in 5.15 (with an
FF exception) vs if you have to wait for 6.

> Pros:
> - users won't have to derive from QProcess to run code in the child
>   process (cleaner API)
> - less fragile in detecting when the user wants to enable
>   child-running code versus having overridden for other reasons

I like more flexibility for users and more robustness.

> Cons:
> - breaks feature freeze, adds SIC for Qt 6

Please clarify: if we include some new API in 5.15 to support this, what
will be the SiC change in Qt 6 ?

> - of the 6 times I can find of QProcess being derived from in Qt & Qt
>   Creator, 5 are to override setupChildProcess anyway and the last one
>   is in tst_QProcess

Does anyone have sources from outside Qt project that are currently
forced to derive from QProcess for the sake of this ?  If so, please try
to work out how Thiago's change would affect you and give the rest of us
a summary.

> - use of std::function<void(void)> in Qt 5 on Unix may not be
>   acceptable (it was for Windows because there are only two compilers)
> 
> Alternative: add the API to Qt 6 and deprecate setupChildProcess(),
> but remove it only in Qt 7. This means we get the benefit of cleaner
> API over time, without the feature freeze exception and potential
> standard library compatibility issue, but makes us keep using
> FORKFD_USE_FORK for other derivation reasons.
> 
> Opinions?

I know that I do not know enough to have a clear opinion.

	Eddy.