One more reason to use posix_spawn() instead of fork() is that the latter must duplicate parent process memory, so for large processes which work under time constraints this can take nontrivial amount of time. This can bite when calling system() to execute shell command, since under the hood it also calls fork().
That is not actually true. Under the hood in the GNU C library system() calls clone().
* https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/pos...
* https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/uni...
Under the hood in the musl C library, system() calls posix_spawn() which in turn calls clone().
* https://git.musl-libc.org/cgit/musl/tree/src/process/system....
* https://git.musl-libc.org/cgit/musl/tree/src/process/posix_s...
For the purposes of this discussion, it doesn't matter whether system() uses clone() or fork() - they have the exact same problem that they have to do a non-trivial amount of virtual address space setup, and can trigger OOM if you don't have overcommit enabled. (Indeed Glibc's fork() is just a wrapper around clone() rather than the legacy fork() syscall.)
> For the purposes of this discussion
On the contrary, the purposes of this discussion were set out by amluto above:
> you should not call fork() [...] Use posix_spawn() or [...] use vfork() or clone().
and by kruzcek:
> This can bite [...] since [...] it also calls fork().
The people at the head of this discussion set out the premise that it very much does matter whether fork() or clone() or vfork() is called, by system() or directly, and this is in fact the very thing that they are discussing.
They are wrong about what system() actually does under the covers, they were slipshod about what C library they were talking about, and like you they have not picked up on the CLONE_VM flag being the important thing when it comes to the memory map, but they are right that there is a difference in the address space work that one has to be careful about and it is not "the exact same problem".
* https://news.ycombinator.com/item?id=9653238
* https://github.com/torvalds/linux/blob/0e9b10395018ab78bf6bf...
vfork() is even harder to use correctly than fork().
posix_spawn() is not a silver bullet either. Its API is cumbersome, it severly limits what you could do in the child process before exec(), and has no sane way to handle errors in the pre-exec() stage.
And AFACIS the glibc implementation of posix_spawn() doesn't even fix the memory duplication problem out of the box. It uses vfork() only if you use the non-standard POSIX_SPAWN_USEVFORK flag.