apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <...@rkbloom.net>
Subject Re: [PATCH] Re: apr_proc_mutex is broken
Date Tue, 19 Nov 2002 19:00:15 GMT

On 19 Nov 2002, Jeff Trawick wrote:

> <rbb@rkbloom.net> 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


View raw message