Aaron Bannert <[EMAIL PROTECTED]> 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 | [EMAIL PROTECTED] | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
