apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <traw...@attglobal.net>
Subject Re: apr_lock.h lock scope question
Date Fri, 22 Jun 2001 14:40:40 GMT
Aaron Bannert <aaron@ebuilt.com> writes:

> > If you use APR_INTRAPROCESS, you will get a light-weight thread locking
> > mechanism.  What more are you looking for.  In reality, for thread
> > locking, we always end up using pthreads mutex's on Unix.
> 
> If by lightweight you mean (in apr_lock_acquire() for example):
> 
> function overhead from apr_lock_acquire()
> a switch statement
> two nested ifs
> function overhead from apr_unix_lock_{inter,intra}()
> another if
> two returns

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.*

*There would have to be an intermediate routine for APR_LOCK_ALL on
most platforms when APR is built with thread support.

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.
-- 
Jeff Trawick | trawick@attglobal.net | PGP public key at web site:
       http://www.geocities.com/SiliconValley/Park/9289/
             Born in Roswell... married an alien...


Mime
View raw message