Aaron Bannert wrote:
>On Tue, Jul 17, 2001 at 10:17:01AM -0700, Brian Pane wrote:
>
>>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.
>>
>
>I wasn't suggesting that, I was suggesting that it's a bad idea to start
>fork()ing off processes from an MPM that's also doing threads and you
>want that fork()ed of process to later do cleanups.
>
I agree.
>My point is it's solely an MPM architecture decision. Are you saying that
>this is a typical scenario?
>
I think it's an atypical scenario, and one that can't be implemented very
well anyway. (The synchronized approach has a performance problem, and
the unsynchronized approach can crash due to a race condition.) Thus my
argument is that this scenario (forking from a threaded MPM and then trying
to clean up the other threads' resources in the child process) isn't a
valid use case for the design of the pools.
--Brian
