posix_spawn and vfork

[Adhemerval Zanella]

On 04/05/2019 06:07, Florian Weimer wrote:
> * Adhemerval Zanella:
> 
>> 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.
> 
> We could specify the returns_twice attribute, then the compiler should
> make it work.
> 
> I would even go so far as to say that doing this is worthwhile because
> it increases test coverage for our vfork implementation.  I think we
> need to provide a working vfork.

The return_twice should indeed help the compiler support, but it would
still need to rely in proper compiler compiler support through an extension
which is in most places sketchy (it may fail in some non define scenario or
with a compiler that does not fully support the attribute). 

> 
>>> 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 we share the stack, like vfork does, all that stack-management code
> isn't necessary anymore.

The current stack allocation thought mmap is only required to handle the
compat handling of script without shebang.  We can optimize it by moving 
it to a compat symbol and providing a simple pre-defined buffer with enough 
stack size so __spawni_child can allocate its automatic variables.  I will
try to spend some time to work on this this week.

> 
> Thanks,
> Florian
>