Return-Path: Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 66770 invoked by uid 500); 29 Dec 2001 19:46:53 -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 66757 invoked from network); 29 Dec 2001 19:46:53 -0000 Date: Sat, 29 Dec 2001 11:46:51 -0800 From: Justin Erenkrantz To: dev@apr.apache.org Subject: Re: APR_HAS_CREATE_LOCKS_NP not defined where it should be Message-ID: <20011229194650.GS29284@ebuilt.com> References: <20011228172247.O1529@clove.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.23.2i X-AntiVirus: scanned for viruses by AMaViS 0.2.1-pre3 (http://amavis.org/) X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N On Sat, Dec 29, 2001 at 09:49:23AM -0500, Jeff Trawick wrote: > I would prefer moving to a situation where the function that allows > you to specify the implementation is always available and > APR_LOCK_DEFAULT is always available. > > One way to do that: > > . get rid of apr_lock_create_np() and apr_proc_mutex_create_np() > > . add new required parameter to apr_lock_create() and > apr_proc_mutex_create() for specifying implementation (expecting > most callers to pass APR_LOCK_DEFAULT) I was about to say the same thing (even had a message written last night to that effect). So, +1. -- justin