Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Date: Fri, 22 Jun 2001 08:38:37 -0700 (PDT)
From: <rbb@covalent.net>
To: Aaron Bannert <aaron@ebuilt.com>
Cc: Jeff Trawick <trawick@attglobal.net>, <dev@apr.apache.org>
Subject: Re: apr_lock.h lock scope question
In-Reply-To: <20010622082701.L5701@ebuilt.com>
Message-ID: <Pine.LNX.4.30.0106220836440.19059-100000@koj.rkbloom.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII


Just for some history.  This was all discussed back when I first designed
the lock API.  Manoj wanted separate functions, I wanted a single
function.  I won, but only because I was the guy implementing it, not
because I was able to convince Manoj technically.  If we want to separate
the functions out now, I say go for it, but we have to leave the old
functions.  Removing the current functions would break too many programs.

Ryan

On Fri, 22 Jun 2001, Aaron Bannert wrote:

> > Actually, I'd like to see function ptrs stored in apr_lock_t so that
> > apr_lock_acquire() and apr_lock_release() can just call the right
> > low-level routine with no checking of the lock type.*
>
> we'd still be looking at minimum 2 function calls per each lock_acquire()
> and lock_release() (and now an extra dereference), but if it gives us
> needed functionality then I'm for it.
>
> > *There would have to be an intermediate routine for APR_LOCK_ALL on
> > most platforms when APR is built with thread support.
>
> I still disagree with apr_lock_*() providing both
> INTRAPROCESS and CROSS_PROCESS  *in the same function calls*.
>
> Why not:
>
> struct apr_lock_inter_mutex_t;
> apr_lock_inter_mutex_init()
> apr_lock_inter_mutex_acquire()
> apr_lock_inter_mutex_release()
> apr_lock_inter_mutex_destroy()
>
> struct apr_lock_mutex_t;
> apr_lock_mutex_init()
> apr_lock_mutex_acquire()
> apr_lock_mutex_release()
> apr_lock_mutex_destroy()
>
> [* function names will change to protect the innocent]
>
>
> Then we can add more lock types as needed that follow the same pattern,
> like the one suggested by kevin seguin for condition variables.
>
> struct apr_condition_t;
> APR_DECLARE(apr_status_t) apr_new_condition(apr_condition_t* cond);
> APR_DECLARE(apr_status_t) apr_destroy_condition(apr_condition_t* cond);
> APR_DECLARE(apr_status_t) apr_condition_wait(apr_condition_t* cond, int
> sec, int nsec);
> APR_DECLARE(apr_status_t) apr_condition_signal(apr_condition_t* cond);
>
>
> > The function ptr based trick for getting to the right low-level
> > code fits well with Jim Jag's suggestion for allowing one APR build to
> > be able to use multiple os-provided lock mechanisms.
> >
> > If we were willing to expose the function ptrs in public header files
> > then apr_lock_acquire() and apr_lock_release() could be macros which
> > jump right to the low-level code.
>
> That would be neat.
>
> Really, aren't we just talking about providing two layers of lock interfaces:
>
> cross-platform (best guess), and
> platform-specific (runtime capability querying)?
>
> -aaron
>
>


_______________________________________________________________________________
Ryan Bloom                        	rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------