> 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
