Aaron Bannert <[EMAIL PROTECTED]> writes:
> What do we do about these _np functions? I've grown quite accustomed to
> being able to switch over to AcceptMutex pthread whenever I want
There is no question that you'll continue to be able to do
"AcceptMutex pthread" :)
, but
> this whole concept goes against the grain in APR. I could go either way
> (for keeping or removing), but aparently others cannot. Duke it out or
> whatever, but let's get this solved.
I would prefer moving to a situation where the function that allows
you to specify the implementation is always available and
APR_LOCK_DEFAULT is always available.
One way to do that:
. get rid of apr_lock_create_np() and apr_proc_mutex_create_np()
. add new required parameter to apr_lock_create() and
apr_proc_mutex_create() for specifying implementation (expecting
most callers to pass APR_LOCK_DEFAULT)
. expose APR_LOCK_SYSVSEM et al on all platforms
apps that don't want a run-time error can check
APR_HAS_foo_SERIALIZE to decide whether they should specify
APR_LOCK_foo
> For now, here's a lame hack for apache to get the AcceptMutex working again
> on the worker MPM under Unix:
or in apr.h
#if APR_HAS_FCNTL_SERIALIZE (may need to check for something else)
#define APR_HAS_CREATE_LOCK_NP 1
#else
#define APR_HAS_CREATE_LOCK_NP 0
#endif
--
Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
