Aaron Bannert wrote:
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.
Synchronizing the forks with pool resource registration isn't a scalable design; it requires locking a process-wide lock every time you want to register a resource in a per-thread pool. It would be a huge mistake to slow down the routine operation of the httpd in order to optimize for fork.
--Brian
