Return-Path: Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 93318 invoked by uid 500); 8 Nov 2002 18:54:56 -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 93302 invoked from network); 8 Nov 2002 18:54:56 -0000 Date: Fri, 08 Nov 2002 10:55:56 -0800 From: Justin Erenkrantz Reply-To: Justin Erenkrantz To: Bill Stoddard , APR Development List Subject: RE: apr_xlate not thread safe Message-ID: <2147483647.1036752956@[10.0.1.11]> In-Reply-To: References: X-Mailer: Mulberry/3.0.0b8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, hits=-8.2 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01 version=2.50-cvs X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N --On Friday, November 8, 2002 10:58 AM -0500 Bill Stoddard wrote: >> > This type of bug is going to bite us over and over. >> >> Does that mean we make every object threadsafe? IMHO, No. > > Oh, I agree for sure. > >> >> Better that we document which returned apr_foo_t's are threadsafe, >> which ones are not, > > Yep. Nah. Subversion was doing something incredibly stupid. We were walking up the pools until it found the global_pool and then created the apr_xlate_t in there and just reused that. The global_pool has no guarantee on being thread-safe within the context of httpd. It has nothing to do with apr_xlate_t. It has everything to do with using the global_pool and the false assumption that it was threadsafe. I don't think it's a big deal that we (in APR) have to worry about, but that's just me. -- justin