Hi,
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of Jeff Trawick
> Sent: 29 December 2001 15:49
> > 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)
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
