Aaron Bannert <[EMAIL PROTECTED]> writes:
> On Sat, Dec 29, 2001 at 04:48:12PM -0500, Jeff Trawick wrote:
> > > > 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.
> >
On Sat, Dec 29, 2001 at 04:48:12PM -0500, Jeff Trawick wrote:
> > > 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 ri
"Sander Striker" <[EMAIL PROTECTED]> writes:
> 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?
I'd rather it be a function than a macr
Hi,
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On 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 when
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 g
There were some changes made recently to accomodate the ackwardness of
the non-portable functions on platforms that have no use for them,
specifically for use in the worker MPM. If APR_HAS_CREATE_LOCKS_NP is
not defined, we no longer use the apr_proc_mutex_create_np() routine.
This seems reasonabl
