When a multi-threaded process calls fork(), ...

When a multi-threaded process calls fork() or _Fork(), ...

the processing performed in the child before fork() returns

the processing performed in the child before fork() or _Fork() returns in the child

When a multi-threaded process calls fork(), although all memory that is addressable in the calling thread remains addressable in the child, there is no guarantee that the contents of thread-specific memory, such as stacks or thread-local storage, that was specific to other threads in the parent will still be the same in the child. This is because such memory could be treated as available in the child given that the threads it related to do not exist in the child, and consequently the processing performed in the child before fork() returns could make use of that memory. Therefore applications should avoid using in the child any pointers to thread-specific memory that were passed to the calling thread from other threads in the parent.

When a multi-threaded process calls fork() or _Fork(), there is no guarantee that thread-specific memory (such as stacks or thread-local storage) associated with threads in the parent other than the calling thread will still be available in the child. This is because threads in the parent other than the calling thread do not exist in the child. Consequently, the implementation of fork() and _Fork() could remove that memory from the address space in the child, or reuse it for other purposes before returning or (in the case of fork()) calling any of the fork handlers registered by pthread_atfork(). Therefore, applications should avoid using any pointers to thread-specific memory in the child that were passed to the calling thread from other threads in the parent.