[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: master 2c79a8f 2/2: Use posix_spawn if possible.

From: Philipp
Subject: Re: master 2c79a8f 2/2: Use posix_spawn if possible.
Date: Tue, 9 Nov 2021 15:46:45 +0100

> Am 08.11.2021 um 12:00 schrieb Aaron Jensen <aaronjensen@gmail.com>:
> Hi all,
> Attached is the posix spawn patch adapted to be only effective on
> Darwin. I chose to leave the patch as-is aside from adding the
> additional conditional, but let me know if I should do something
> different. It wasn't clear where things stood in terms of whether or
> not we would ever want to use posix_spawn on non-darwin OSes.

I guess either way is fine.  I'd slightly lean towards enabling it whenever 
it's available (i.e. remove the condition on DARWIN_OS):

1. The libc implementation of posix_spawn can make use of system-specific 
implementation improvements.  For example, GNU libc on GNU/Linux uses the 
`clone' system call instead of `vfork' to create a separate stack for the 
2. Since it's easier to run a continuous integration suite on free OSes, by 
exercising the posix_spawn code path on them we can improve test coverage.
3. Using posix_spawn is simpler since it's not possible to accidentally 
introduce undefined behavior (by calling an async-signal-unsafe function in the 

My original motivation for dropping the posix_spawn branch was that we'll have 
to maintain the fork/exec branch for the foreseeable future and that there's no 
measurable benefit from using posix_spawn, so it would just be additional code 
to maintain.  Since that argument is no longer correct, we might as well use 
posix_spawn where possible.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]