3 ms·

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/posix/system

• antientropic 8y ago
  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.)
  • JdeBP 8y ago
    > 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://news.ycombinator.com/item?id=9653238 * https://github.com/torvalds/linux/blob/0e9b10395018ab78bf6bffcb9561a703c7f82cee/kernel/fork.c#L1322 https://github.com/torvalds/linux/blob/0e9b10395018ab78bf6bf...