apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@covalent.net>
Subject Re: cvs commit: apr/locks/netware global_mutex.c
Date Thu, 21 Feb 2002 00:23:05 GMT
From: "Aaron Bannert" <aaron@clove.org>
Sent: Wednesday, February 20, 2002 4:13 PM


> On Wed, Feb 20, 2002 at 02:27:37PM -0600, William Rowe wrote:
> > 
> > The more I consider the win32 fix, this netware and the coming BeOS fix, I believe
we need
> > two symbols;
> > 
> > APR_GLOBAL_MUTEX_IS_THREAD_MUTEX
> > 
> > and
> > 
> > APR_GLOBAL_MUTEX_IS_PROC_MUTEX
> > 
> > and pull off all the magic in apr_global.h.  Unless threadproc [global] mutexes
are custom,
> > it seems Win32/OS2 can simply use defines to apr_proc_mutex (APR_GLOBAL_MUTEX_IS_PROC_MUTEX),

> > while Netware and BeOS can simply use apr_thread_mutex (APR_GLOBAL_MUTEX_IS_THREAD_MUTEX).
> 
> These are implementation details, so I don't see why they need to be
> defined globally (in apr.h, if I'm understanding you correctly). I do
> agree, however, that the extra function call is unnecessary. Can we use
> APR_INLINE? An alternative would be to #define APR_PROC_MUTEX_IS_GLOBAL
> in the include/arch/<foo>/proc_mutex.h and let that dictate how
> global_mutex.c is implemented per platform (or in the default impl.).

Name, please, one place where APR_INLINE actually inlines squat today.


Mime
View raw message