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
