The root of the problem is threading, and that exact same problem exists everywhere else. Historically, the behavior when both forking and threading was never well defined. The old rule was, never fork after starting a thread. And this rule still persists, even on systems like Solaris and Linux which actually try hard to make simultaneous forking and threading safe.
Now, if a third-party library starts up threads in the background, then it follows that the application should never fork after entering that library. If the application is linking that library at load-time, at the library initializes itself by starting threads, then technically the application should never, ever call fork.
Presumably, then, it would seem that some of Apple's libraries immediately spin up threads in the background (and/or initialize similar resources which don't behave well with fork). This is nothing new.
Posted Oct 11, 2012 10:10 UTC (Thu) by nix (subscriber, #2304)
[Link]
Well, this sort of thing is why pthread_atfork() was invented, so that libraries could hide their threaded implementation from their users. A properly written threaded library should not prevent its callers from forking.