Re: system and popen fail in case of big application

[Szabolcs Nagy <szabolcs.nagy@arm.com>]

On 12/09/18 17:29, Zack Weinberg wrote:
> I don't want to encourage people to use posix_spawn because
> posix_spawn is a badly designed API.  It's difficult to use correctly.
> It's *tedious* to use correctly, which means people won't bother.  It
> can't do everything you might want to do on the child side (witness
> the discussion of adding an extension to let it do chdir()).  Its
> behavior in case of errors is underspecified.  And it might be

the misdesigned api is vfork: it is not just difficult to use
correctly but impossible: it breaks c language semantics
(gcc fixes this up to some extent when it sees the actual vfork
symbol in the code, but there is no guarantee in c that the
compiler can see that, and even then the shared stack between
parent and child has various issues as Adhemerval described)

so stop telling ppl to use vfork.

fork has the problem of large commit charge so it can fail with oom,
it's also not implementable efficiently on various systems (no-mmu,
windows, etc) can easily cause leaks of sensitive data into
child processes (hard to provide security boundary between parent
and child during the critical operations before exec)

posix_spawn is ugly but at least was designed with the c language
in mind and currently it's the only api that avoids the problems
listed above, so until there is a better api, this is what should
be recommended for process creation (e.g. gnu make would benefit
from it, its vfork usage is a pile of UB)

> implemented in terms of fork, which means it doesn't guarantee to
> solve Sergey's problem.

vfork can be implemented in terms of fork too, memcpy can be
implemented using syscalls, these are QoI issues and not
good technical reasons to avoid a particular api. (the entire
point of posix_spawn is that it does not depend on the va
space copy semantics of fork, the way glibc ignored this for
a long time was just a glibc bug)