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_HAS_CREATE_LOCKS_NP not defined where it should be
Date Sat, 29 Dec 2001 14:49:23 GMT
Aaron Bannert <aaron@clove.org> 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 | 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