On Mon, Nov 19, 2001 at 12:09:56PM -0800, Ryan Bloom wrote:
> On Monday 19 November 2001 09:19 am, Aaron Bannert wrote:
> > What is the right way to handle this? I don't think we should we be
> > conditionally compiling declarations, only implementations. We can
> > either go for runtime errors (APR_ENOTIMPL) when functionality is
> > non-existant (--disable-threads), or we'll have to go around putting #if
> > blocks around all the code references.
>
> We should always opt for compile time errors over run-time errors, because
> it makes the error easier to see and fix. I would say, fix mod_ssl by #if'ing
> the code.
There are many other places where we make calls to the lock API without
checking APR_HAS_THREADS. I'm not so sure anymore that APR_HAS_THREADS
is even appropriate for the entire lock API (eg. crossprocess locks).
For the locks that do depend on a threading library (apr_thread_*_t)
how about we #error if the header was included but APR_HAS_THREADS
is not defined?
Something like this?
Index: apr_thread_mutex.h
===================================================================
RCS file: /home/cvs/apr/include/apr_thread_mutex.h,v
retrieving revision 1.4
diff -u -u -r1.4 apr_thread_mutex.h
--- apr_thread_mutex.h 2001/10/17 00:33:00 1.4
+++ apr_thread_mutex.h 2001/11/19 20:30:25
@@ -59,12 +59,14 @@
#include "apr_pools.h"
#include "apr_errno.h"
+#ifndef APR_HAS_THREADS
+#error Threads must be enabled to use the apr_thread_mutex.h interface
+#endif
+
#ifdef __cplusplus
extern "C" {
#endif /* __cplusplus */
-#if APR_HAS_THREADS
-
/**
* @file apr_thread_mutex.h
* @brief APR Thread Mutex Routines
@@ -127,8 +129,6 @@
* @return apr_pool_t the pool
*/
APR_POOL_DECLARE_ACCESSOR(thread_mutex);
-
-#endif
#ifdef __cplusplus
}
