<[EMAIL PROTECTED]> writes: > As for the app needing to know about every use of > fork/apr_proc_fork in every library, that isn't true. The app needs to > know about every use of apr_terminate in every library. It is the > apr_terminate call that is causing the problem, not the actual fork() > call.
APR states that apr_terminate must always be called, and suggests installing apr_terminate as an atexit handler. The only APR application I've worked on (Subversion) does this. This means every fork-and-exit is a potential problem. Suppose I writing a library that uses proc_mutex. I do not know whether the application has installed apr_terminate as an atexit handler. > However, if the app removes the proc_mutex cleanup before the new > process is spawned, it won't have to worry about this, because the child > process won't have a cleanup to kill. So in practice some (lots? most? all?) libraries/applications will kill it. Why bother registering it? Let the user choose to register such a cleanup if required. There are two possible errors: - The application can fail to kill the cleanup, in which case a problem may occur if apr_terminate runs. Whether this is a problem depends on what the child processes do, if they only exit in exceptional circumstances the bug may not be readily apparent. - Or the application can fail to destroy the mutex, a fairly conventional resource deallocation bug. I spent some time debugging a Subversion pool cleanup handler that erroneously deleted a temporary file when forking a child process, I know I would prefer the latter! -- Philip Martin
