On 19 Nov 2002, Jeff Trawick wrote:
> <[EMAIL PROTECTED]> writes: > > > This would be a bad design change IMNSHO. The library has no business > > deciding when a mutex is destroyed, that is the role of the application > > that created the mutex. It isn't too hard to imagine a situation where a > > mutex is created in the parent process, but the child processes are the > > only ones that know anything at all about when it is safe to destroy it. > > The app must be the thing that decides when to close the mutex. > > Perhaps I'm missing something obvious, but the app doesn't seem to > have much control over when the mutex is destroyed. Either it calls > apr_terminate() or not, which isn't a very nice way to control it. You already responded to my apr_pool_cleanup_kill post, so this question is moot now. :-) > An app could do what Apache does and allocate the mutex from a pool > which is never cleaned up (app doesn't call apr_terminate() but is > careful to clean up all pools except for the one with the mutex in > it). Which leaves my reason for even responding to this note. If this is actually what Apache is doing, then Apache has a huge bug. Apr_terminate shouldn't have any concept of a pool that shouldn't be destroyed, all it is doing, is destroying the global_pool, which should be the parent of all pools. Apache should definately switch to having the child processes call apr_terminate() correctly. For that matter, Apache child processes should also probably call apr_initialize(). Having a pool that never gets cleaned up is asking for somebody to misuse the pool and to have resources leak. Ryan
