> I'm not sure that the alternative is workable, either. > > At the time of the fork, when the child process gets a snapshot of > the parent's memory, it's possible that some thread other than the one > invoking fork could be halfway through registering a new resource (e.g., > file descriptor) in its pool. There's no guarantee that it's safe to > attempt a cleanup of that other thread's pool in the child process; > if the fork has caught the data structures in an intermediate state, > attempting to destroy that pool might yield a segv.
Correct me if I'm wrong, but that would be a property of a buggy MPM. If the MPM chooses to mix non-synchronized fork()s and thread invocation, than that's what it gets. -aaron
