apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Bannert <aa...@ebuilt.com>
Subject Re: apr_lock.h lock scope question
Date Fri, 22 Jun 2001 15:27:01 GMT
> 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;

struct apr_lock_mutex_t;

[* 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)?


View raw message