This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: posix_spawn and vfork
* Adhemerval Zanella:
> 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).
If we want to go this route, I'd suggest something like this as a
building block:
pid_t clone_samestack (unsigned int flags, void (*action) (void *)
void *closure);
and it would be a fatal error if ACTION (CLOSURE) returns. The function
would fail with EINVAL if FLAGS contained CLONE_VM without CLONE_VFORK.
Once we have that, the need for explicit stack management goes away.
Thanks,
Florian