Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
From: "Sander Striker" <striker@apache.org>
To: "William A. Rowe, Jr." <wrowe@rowe-clan.net>
Cc: <dev@apr.apache.org>
Subject: RE: unix/thread_mutex.c 1.19 and --enable-pool-debug=yes core  dump
Date: Fri, 22 Aug 2003 16:00:16 +0200
Message-ID: <JLEGKKNELMHCJPNMOKHOCEADLIAA.striker@apache.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
In-Reply-To: <5.2.0.9.2.20030822011834.04554210@pop3.rowe-clan.net>
Importance: Normal

> From: William A. Rowe, Jr. [mailto:wrowe@rowe-clan.net]
> Sent: Friday, August 22, 2003 8:20 AM

> My thought is that the existing code is resilient enough without any
> cas logic; but I have been waiting for others to take the time to prove
> that to themselves before we back down to simple inc/dec/assignment.
> 
> My other question - why is it necessary to explicitly use nested locks
> within the pool code?  Do we have a nesting issue that could be fixed
> and return to more optimal 'default' thread mutexes for pools?

This only for the pools debug code.  From apr_pool_create_ex_debug:

        /* No matter what the creation flags say, always create
         * a lock.  Without it integrity_check and apr_pool_num_bytes
         * blow up (because they traverse pools child lists that
         * possibly belong to another thread, in combination with
         * the pool having no lock).  However, this might actually
         * hide problems like creating a child pool of a pool
         * belonging to another thread.
         */


Sander