From dev-return-8439-apmail-apr-dev-archive=apr.apache.org@apr.apache.org Tue Nov 19 18:51:23 2002 Return-Path: Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 43579 invoked by uid 500); 19 Nov 2002 18:51:23 -0000 Mailing-List: contact dev-help@apr.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Delivered-To: mailing list dev@apr.apache.org Received: (qmail 43568 invoked from network); 19 Nov 2002 18:51:22 -0000 Date: Tue, 19 Nov 2002 11:00:15 -0800 (PST) From: To: Jeff Trawick cc: Philip Martin , Aaron Bannert , Subject: Re: [PATCH] Re: apr_proc_mutex is broken In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N On 19 Nov 2002, Jeff Trawick wrote: > 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