4 ms·

Not a very good article IMHO. In addition to not explaining things well, it doesn't discuss posix_spawn or clone which are much preferable and more extensible w

• inetknght 7y ago
  > posix_spawn or clone which are much preferable and more extensible ways to launch processes. My understanding is that `fork()` is a nice wrapper around `posix_spawn` and, in particular, `clone()`. And in some ways you're right: as an experienced developer I can really appreciate the extensibility of using `clone()` instead of `fork()`. Unfortunately if I were to use `clone()` _ever_ then I would be immediately chastized by the architecture lead. He's not a C dude. I don't think he even understands the concept of programs sharing an address space (he's also anti-thread). All of it stems from "make programs simple" in an effort to minimize maintenance costs down the road. And in many ways he's right too. `clone()` is anything but simple despite being more extensible and `posix_spawn()` is just a more complex `fork()` in that regard.
  • gpderetta 7y ago
    > My understanding is that `fork()` is a nice wrapper around `posix_spawn` . Not really, you can't implement fork on top of POSIX spawn, but you can do the reverse. On linux they are both implemented on top of a lower lower level primitive (clone).
  • dooglius 7y ago
    posix_spawn is a wrapper around fork/do some setup/exec which is the most common way fork is used. Also, fork is normally implemented as a wrapper around clone FWIW. > I don't think he even understands the concept of programs sharing an address space (he's also anti-thread). Personally, I find it easier to reason about than both the parent and the child having the same return stack but YMMV.