system and popen fail in case of big application

[Szabolcs Nagy]

On 14/09/18 19:42, Zack Weinberg wrote:
> On Thu, Sep 13, 2018 at 8:11 AM Szabolcs Nagy <szabolcs.nagy@arm.com> wrote:
>> 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)
> [etc]
> 
> The way I see it is that that is all stuff that could be fixed.  I
> looked at what Adhemerval did in s/u/s/linux/spawni.c and it appears
> that generalizing it to `pid_t nvfork(void (*)(void *))` would solve
> _all_ of the problems you list and even be safe to expose to
> applications.  (Name provisional.)
...
> If we were going to add the hypothetical nvfork(), I would write into
> its documentation that it is _guaranteed_ to have vfork-like behavior
> (that is, it calls the supplied procedure in the memory space of the
> parent process; writes through the closure parameter are visible to
> the caller, as are any changes to errno; control does not return to
> the caller until the procedure finishes) and it will fail and set
> errno to ENOSYS if the OS doesn't make that possible.

i think a new api is fine, but it needs to be proposed
as standard api (or discussed with other implementors
as a glibc only api would be suboptimal).

and it needs to be specified what the callback can do.
e.g. in multi-threaded process only as-safe operations
can be allowed.

and if the vforked child vforks another child which kills
its parent then the original calling thread continues
while the grand child still executes in the same address
space, so either vfork after vfork should be disallowed
or the vforked child needs to run on a separate stack
(if it has its own stack then the caller does not even
need to stop).