apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Bannert <aa...@clove.org>
Subject Re: cvs commit: apr/locks/netware global_mutex.c
Date Wed, 20 Feb 2002 22:13:07 GMT
On Wed, Feb 20, 2002 at 02:27:37PM -0600, William Rowe wrote:
> What's gotten into this list lately :-?  apr_p[c]alloc() always succeeds or we fault
...
> we do _not_ test p[c]alloc throughout the code :)

+1 (OOM is not a portable condition)

> And, if I can ask, what is the problem with returning apr_thread_mutex results, and letting
> apr_thread_mutex do the work [of allocation]?
> 
> 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.).

-aaron

Mime
View raw message