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

[Thiago Macieira]

Sorry, this just occurred to me. This is a request for 5.15 feature freeze 
exception.

Re: https://bugreports.qt.io/browse/QTBUG-17331
Re: 97645478de3ceffce11f58eab140c4c775e48be5
("QProcess: use FFD_USE_FORK when the class is not QProcess itself")

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?

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

Cons:
- breaks feature freeze, adds SIC for 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
- 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 an 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?
-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products