Re: posix_spawn and vfork

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

On 04/05/2019 12:59, Paul Eggert wrote:
> Florian Weimer wrote:
> 
>> doing this is worthwhile because
>> it increases test coverage for our vfork implementation.  I think we
>> need to provide a working vfork.
> 
> Yes; regardless of whether we use vfork to implement posix_spawn, too many programs rely on vfork to withdraw it any time in the foreseeable future.

That does not mean we should *promote* the interface, which has a lot
of downsides and are tricky to use correctly.  If we do want to support
a vfork-like interface I would work toward Zack Weinberg suggestion to add 
a callback 'pre-fork' routine and extend it to make it possible to user
supply a stack.  

Something like:

pid_t xfork (void *(*pre_fork (void *), void *stack, size_t stacksize);

It will make the required libc handling (disable asynchronous cancellation,
block all signals, call the syscall primitive with required flags, restore
signal handling, re-enable asynchronous cancellation, handle error state).
The stack is optional and using NULL will make it use a automatic allocate
one (not sure if issuing a VLA is worth based on stacksize or use a 
pre-defined value).

With some care it would be possible to use on even signal handling (assuming
the callback only uses async-signal-safe functions), even on sigaltstack
signal handlers.