mikeash.com pyblog/friday-qa-2012-01-20-fork-safety.html comments

mikeash - 2012-01-22 19:14:23

Sun, 22 Jan 2012 19:14:23 GMT

Copy on write is an optimization and an implementation detail. Conceptually, the two processes have separate copies of everything from the beginning. Thus a copy gets created if either side modifies memory.

Heath Borders - 2012-01-22 17:35:28

Sun, 22 Jan 2012 17:35:28 GMT

Does the child's copy-on-write view of the parent change when the parent changes memory? Does the memory only copy if the child modifies it, or if either the child or parent modify it?

Gwynne Raskind - 2012-01-21 04:26:04

Sat, 21 Jan 2012 04:26:04 GMT

Russell F.: The article actually answers that question, with a little inference: Almost nothing is safe to do between fork() and exec(). CoreFoundation detects the case where you try to do something with it at such a time and blows up on that symbol because that's the easiest way to tell you what went wrong without trying even more things that potentially aren't safe.

Russell F. - 2012-01-21 03:20:16

Sat, 21 Jan 2012 03:20:16 GMT

This is a great discussion of fork()/exec() from a general Unix viewpoint, but I was hoping to see additional commentary on Mac-specific issues, such as the reason why there is a function called __THE_PROCESS_HAS_FORKED_AND_YOU_CANNOT_USE_THIS_COREFOUNDATION_FUNCTIONALITY___YOU_MUST_EXEC__() :-).

Ben G. - 2012-01-20 17:08:48

Fri, 20 Jan 2012 17:08:48 GMT

Another important thing to note is that, unlike file descriptors, Mach ports are *not* cloned after a fork.

Even if you're careful to only use a single thread in your process, and set up all your Mach ports before fork()ing, all Mach ports in your process are invalidated when you fork. (More specifically, the kernel just doesn't duplicate the ports into the new process.)