Return-Path: Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 16627 invoked by uid 500); 26 Dec 2001 06:02:14 -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 16616 invoked from network); 26 Dec 2001 06:02:14 -0000 Date: Tue, 25 Dec 2001 22:02:24 -0800 From: Justin Erenkrantz To: Jeff Trawick Cc: dev@apr.apache.org Subject: Re: cvs commit: apr STATUS Message-ID: <20011226060223.GB1439@ebuilt.com> References: <20011212100554.5944.qmail@icarus.apache.org> <20011226005643.GZ1439@ebuilt.com> <20011226022100.GA1439@ebuilt.com> 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 Tue, Dec 25, 2001 at 09:47:12PM -0500, Jeff Trawick wrote: > Other than performance, why should the caller care? The lock can't > block. Unbeknownst to the caller we or libc get locks on other > callers. > > Still curious, Hmm. Let me try and restate it. It's a feeling that doing this would be more than simply "creating" a lock - we're also "testing" it. I absolutely see why we need it, but it makes me uneasy to do this automatically in all cases. I wish that this were an option that the caller could opt-in. Consider the case of doing system-call tracing (via truss or strace or ktrace). You'll get possibly confused by having the extraneous lock/unlock. If you look at the APR calls on the surface, you wouldn't know that there is an extra lock/unlock done on this new lock at creation-time. Other than the option/flag alternative, I'm not seeing another way to do this. And, I believe that we should catch this at creation time, so... -- justin