Re: posix_spawn and vfork

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

On 02/05/2019 09:18, Florian Weimer wrote:
> Why do we use clone instead of vfork in posix_spawn?

Besides being deprecated by POSIX, the main issue currently it lacks
a *proper* way to setup a correct stack frame for helper process.
Even with a function, we are relying on undefined semantic that compiler
won't clobber the stack.

> 
> I think we could use vfork and a call to a separate function for the
> subprocess code, as a compiler barrier, and therefore avoiding stack
> clobbering issues.

Why circle back to vfork? Current clone usage already provides all the
required work avoid all the pitfalls we worked to fix for posix_spawn.

> 
> As a result, we can reuse the existing stack and would not have to
> allocate a new one.

Is it really a bottleneck you think work of using a deprecated and
tricky interface instead? Also, we will need to take of the compatibility
handling (maybe_script_execute) which is the main culprit of the stack
requirement (besides -fstack-check).  One possibility is add a compat
symbol and remove maybe_script_execute, but not sure if worth the trouble.

> 
> If this reasoning is incorrect, I'll gladly write up the explanation as
> a new comment for sysdeps/unix/sysv/linux/spawni.c.
> 
> Thanks,
> Florian
>