3 ms·

> He misses the main problem with fork which is poor interaction with threads. That's a problem with threads, not fork(). It generalizes to all sorts of thing

• arghwhat 9y ago
  It sounds to me like fork() is unable to handle threads, unlike clone(). I would therefore say that fork() is to blame. Of course, it is a bit of nitpicking, as the problem is that they do not work well when combined.
  • cryptonector 9y ago
    clone() can't either, if you call it like fork(). It's the semantics of fork() that are the problem.
    • arghwhat 9y ago
      The difference being that the semantics of fork() are optional with clone(), not with fork(). Thus, I would say that clone() can handle the situation.
      • cryptonector 9y ago
        That's the point of clone(), but the point is that the problems of fork() are with its semantics. Even with clone(), if you want to spawn a new process then your best bet is to go with vfork() semantics -- in principle you could create a thread-like process sharing the parent's address space that can then exec() without affecting the parent, but in practice you can only do this inside a C library because the protocol for setting up TLS (for errno) is underdocumented and requires knowledge of and access to your C library's internals.