This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: system and popen fail in case of big application
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).