apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sander Striker" <stri...@apache.org>
Subject RE: APR_HAS_CREATE_LOCKS_NP not defined where it should be
Date Sat, 29 Dec 2001 15:26:37 GMT
Hi,

> From: trawick@rdu163-40-092.nc.rr.com
> [mailto:trawick@rdu163-40-092.nc.rr.com]On Behalf Of Jeff Trawick
> Sent: 29 December 2001 15:49
> > 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)

What about defining apr_lock_create() as:

#define apr_lock_create(params) \
    apr_lock_create_ex(params, APR_LOCK_DEFAULT)

And introduce apr_lock_create_ex which has the extra required parameter?

> .. 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
[...]

> Jeff Trawick

Sander




Mime
View raw message