Re: system and popen fail in case of big application

[Adhemerval Zanella <adhemerval dot zanella at linaro dot org>]

On 17/09/2018 03:32, Szabolcs Nagy wrote:
> 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).

I am not very found of callback mechanism exactly because of your
example, where we need to either specify the possible multiple
interactions by limiting the kind of computation the callback is
allowed to do or just define such invalid computation as unsupported.

For instance, Florian has brought up the discussion about whether or
not support C++ exceptions inside signal handlers and a possible
issue might apply here: should we support C++ code in callback (since
it might trigger non as-safe code with unwinder on a exception)?
Another example is should we handle thread cancellation on callback,
since some async-safe functions might block (fsync or select for 
instance)?

These are just examples of kind of complexity it brings where you
allow unbounded computation on callbacks (even when you specify which
kind of semantics you intend to allow).