> 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
- request_rec question Brian Pane
- Re: request_rec question rbb
- Re: request_rec question Ian Holsman
- Re: request_rec question rbb
- Re: request_rec question dean gaudet
- Re: request_rec question Brian Pane
- Re: Terminating threads in a process, WA... Aaron Bannert
- Re: Terminating threads in a process, WA... rbb
- Re: Terminating threads in a process, WA... William A. Rowe, Jr.
- Re: Terminating threads in a process,WAS... Brian Pane
- Re: Terminating threads in a process,WAS... Aaron Bannert
- Re: Terminating threads in a process,WAS... Brian Pane
- Re: Terminating threads in a process, WA... Aaron Bannert
- Re: Terminating threads in a process,WAS... Brian Pane
- Re: Terminating threads in a process, WA... Aaron Bannert
- Re: Terminating threads in a process, WA... Luke Kenneth Casson Leighton
- Re: Terminating threads in a process, WA... dean gaudet
- Re: Terminating threads in a process, WA... Aaron Bannert
- Re: Terminiting threads in a process RE:... dean gaudet
- Re: Terminiting threads in a process RE: [PAT... Justin Erenkrantz
- RE: Terminating threads in a process, WA... Sander Striker