Return-Path: Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 42041 invoked by uid 500); 20 Jul 2003 18:28:34 -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 41992 invoked from network); 20 Jul 2003 18:28:29 -0000 Date: Sun, 20 Jul 2003 14:28:31 -0400 (EDT) From: Cliff Woolley X-X-Sender: jcw5q@cobra.cs.Virginia.EDU To: dev@apr.apache.org Subject: Re: cvs commit: apr/memory/unix apr_pools.c In-Reply-To: <20030718231005.61031.qmail@icarus.apache.org> Message-ID: References: <20030718231005.61031.qmail@icarus.apache.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N On Fri, 18 Jul 2003 striker@apache.org wrote: > =================================================================== > RCS file: /home/cvs/apr/memory/unix/apr_pools.c,v > retrieving revision 1.196 > retrieving revision 1.197 > diff -u -r1.196 -r1.197 > --- apr_pools.c 28 May 2003 04:39:42 -0000 1.196 > +++ apr_pools.c 18 Jul 2003 23:10:04 -0000 1.197 > @@ -856,7 +856,7 @@ > #if APR_HAS_THREADS > apr_thread_mutex_t *mutex; > > - if ((mutex = apr_allocator_mutex_get(allocator)) != NULL) > + if ((mutex = apr_allocator_mutex_get(parent->allocator)) != NULL) > apr_thread_mutex_lock(mutex); > #endif /* APR_HAS_THREADS */ Yes, definitely correct. Though what about line 864, which says: pool->sibling->ref = &pool->sibling; Are the pool->sibling pointers uniformly protected by the pool->parent mutex? I haven't investigated all of the implications yet, but it seems like that might cause problems as well. --Cliff