Return-Path: Delivered-To: new-httpd-archive@hyperreal.org Received: (qmail 7290 invoked by uid 6000); 1 Oct 1999 14:45:11 -0000 Received: (qmail 7271 invoked from network); 1 Oct 1999 14:45:09 -0000 Received: from fwns2d.raleigh.ibm.com (HELO fwns2.raleigh.ibm.com) (204.146.167.236) by taz.hyperreal.org with SMTP; 1 Oct 1999 14:45:09 -0000 Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id KAA29552 for ; Fri, 1 Oct 1999 10:44:52 -0400 Received: from chosondo.raleigh.ibm.com (chosondo.raleigh.ibm.com [9.37.73.195]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id KAA18544 for ; Fri, 1 Oct 1999 10:44:53 -0400 Date: Fri, 1 Oct 1999 10:44:58 -0400 (EDT) From: Ryan Bloom To: new-httpd@apache.org Subject: Re: APR locks In-Reply-To: <87ogejuq3h.fsf@pobox.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: new-httpd-owner@apache.org Precedence: bulk Reply-To: new-httpd@apache.org > Well that's not right! It's a legacy of the Unix pools not needing > any multiplexing. So, the current APR lock API isn't clever enough - > i.e. apr_lockscope_e is missing APR_LOCK_NONE. Easy enough to put it in. :) > > apr_lock.h belongs in apr_lib.h not apr_portable right? It definately NEEDS to be in apr_portable, but it also needs to be in apr_lib. It's an oversight. :) > The dispatch to flavor of lock can be engineered N ways: > a. PROPOSED?: do it in source at callers. > b. AS in 1.3: do it at compile time, in the headers. > c. APR design: do it at runtime. > d. The every popular: assorted section of the above. > > I like b more than a, because the current primary user is already > coded to have treat the mutex as an abstraction. I like c more > that b, but only slightly because I have heroic fantasies of > pools and i/o pipelines that work in all three ways: user-serialized, > intra-process, inter-process. But then it is always dangerous > to encourage such enthusiasms. I agree. I think if we are going to divide the locks in any way at all, it needs to be on type oif lock not scope of lock. A lock is a lock is a lock, whether that lock is cross process or cross thread shouldn't matter, it is doing the same thing. Protecting a section of code. To break the locks based on what they are affecting doesn't make any sense to me. It make more sense to break them on how they are protecting it. But, that is a discussion for another day. :) Ryan _______________________________________________________________________ Ryan Bloom rbb@raleigh.ibm.com 4205 S Miami Blvd RTP, NC 27709 It's a beautiful sight to see good dancers doing simple steps. It's a painful sight to see beginners doing complicated patterns.