summaryrefslogtreecommitdiffstats
path: root/src/corelib/io/qprocess_unix.cpp
diff options
context:
space:
mode:
authorOswald Buddenhagen <oswald.buddenhagen@gmx.de>2020-11-06 16:15:37 +0100
committerOswald Buddenhagen <oswald.buddenhagen@gmx.de>2020-11-16 02:17:28 +0100
commitd6bf71123d3ef073f25610345cb5dc920e4fb783 (patch)
tree9aa7e7471054f9f3f6cbb301a7a3074fac624318 /src/corelib/io/qprocess_unix.cpp
parentcc280e6df1d1995504399fd2882489247b548198 (diff)
don't ever force fork() instead of forkfd()
this implements a suggestion made by a comment that got lost in 028ddf363: as explained in 97645478's commit message, we were forcing use of fork() because we couldn't be sure that the code in a custom setupChildProcess() did not rely on pthread_atfork() callbacks being called. however, that in turn was inconsistent with the default behavior, and made customizing QProcess mutually exclusive with benefitting from forkfd(). use the opportunity presented by changing the method of modifying child process behavior to also change this. this also amends 4e2f4670, as most of the now deleted comment in fact related to the use of vfork semantics, which we don't do anymore. [ChangeLog][Important Behavior Changes][QtCore][QProcess][Unix] pthread_atfork() callbacks are consistently not invoked on reasonably recent Linux and FreeBSD systems any more. This was already the case in later Qt 5 releases, unless setupChildProcess() was overridden. Change-Id: Icb239e4d2c705bf4665589469022a521267f7db5 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Diffstat (limited to 'src/corelib/io/qprocess_unix.cpp')
-rw-r--r--src/corelib/io/qprocess_unix.cpp10
1 files changed, 0 insertions, 10 deletions
diff --git a/src/corelib/io/qprocess_unix.cpp b/src/corelib/io/qprocess_unix.cpp
index 1111e6e607..f791ee94ee 100644
--- a/src/corelib/io/qprocess_unix.cpp
+++ b/src/corelib/io/qprocess_unix.cpp
@@ -450,17 +450,7 @@ void QProcessPrivate::startProcess()
workingDirPtr = encodedWorkingDirectory.constData();
}
- // Select FFD_USE_FORK and FFD_VFORK_SEMANTICS based on whether there's
- // user code running in the child process: if there is, we don't know what
- // the user will want to do, so we err on the safe side and request an
- // actual fork() (for example, the user could attempt to do some
- // synchronization with the parent process). But if there isn't, then our
- // code in execChild() is just a handful of dup2() and a chdir(), so it's
- // safe with vfork semantics: suspend the parent execution until the child
- // either execve()s or _exit()s.
int ffdflags = FFD_CLOEXEC;
- if (childProcessModifier)
- ffdflags |= FFD_USE_FORK;
// QTBUG-86285
#if !QT_CONFIG(forkfd_pidfd)