On Monday, 2 January 2023 16:51:47 -03 Tom Honermann via SG16 wrote:
> Unfortunately, use of fork() in multithreaded programs is problematic.
> Only the calling thread is cloned in the child process. This can result
> in the child process being in a state where thread synchronization
> resources (such as those that might be used by a thread-safe
> implementation of getenv() and/or putenv()) may be in a permanently
> locked state such that an attempt to modify the environment might result
> in a deadlock.

That's why you have be very careful with what you call between fork() and
execve(). A good rule of thumb is that async-safe functions are also safe in
fork, though there are a couple of exceptions.

We don't need to design our content so that it works in those cases. Even in
the case of preparing the environment for the a child process, you'd prepare
everything *before* the fork, so you can deal with as much of the error
conditions before you fork(). Reporting errors from the fork side is
cumbersome -- there's a standard technique, but that extra pipe is not free.

> I think Jeff's future work to add process spawning support to the C++
> standard library should build on posix_spawn()
> <https://pubs.opengroup.org/onlinepubs/9699919799/functions/posix_spawn.html
> > with more emphasis on providing a suitable environment than on modifying
> the current environment to suit the needs of the child process. I have long
> wished that POSIX included functions similar to
> posix_spawnattr_setflags()
> <https://pubs.opengroup.org/onlinepubs/9699919799/functions/posix_spawnattr_
> setflags.html> that enabled adding per-environment-variable mutation
> options. E.g., something like posix_spawnattr_inheritenv(true),
> posix_spawnattr_setenv("FOO", "VALUE"), posix_spawnattr_unsetenv("FOO"),
> posix_spawnattr_appendenv("PATH", ";", "/path/to/bin"). Similar
> functionality for Microsoft's CreateProcess() suite of functions would
> be welcome as well.

Indeed and we're turning towards that in QProcess too. For historical reasons,
we must still allow for user code to run in the fork side before execve(), but
I have a plan to add spawnattr-like functionality to deal with the majority of
things people want to do in that child. If QProcess knows what needs to be
done, it won't have to give up pidfd support.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel DCAI Cloud Engineering