>Wrong, you can fork() and only the thread issuing the fork () call survives the fork(), for example. Thinking about it, it makes perfect sense. Threads are p

>Wrong, you can fork() and only the thread issuing the fork () call survives the fork(), for example. Thinking about it, it makes perfect sense. Threads are processes that share the same memory space. When a thread is created (via pthread_whatever() or clone()) it starts executing some code that is practically in a $RANDOM place. So how would one go about copying the state of a process that has threads ? Freeze all the threads and copy everything ? That way the thread, that is probably doing some job at the moment, would end up being cloned without it knowing. So you would get two processes (threads are processes) that are doing exactly the same thing. Until something external changes their (internal) state, that is. Non-determinism should always be avoided if possible. This still does not say that one couldn't write portable, threaded, UNIX compliant code. Nor that those undefined behaviors from the specs would be fixable by rewriting the spec (by adding atomic fork+exec, that seems to me to be the context of this whole thing).