Per Aaron's consent that there is no more rational way to optimize this

  relationship - allow Win32/Netware [and perhaps, some unix-ish platforms
  that don't have a 'proc lock not typesafe' construct] to 'borrow' the
  proc_mutex code.  Because the apr_thread_lock_create call differs so
  significantly, global locks can never be implemented in terms of thread
  locks [as well as the converse.]


git-svn-id: http://svn.apache.org/repos/asf/apr/apr/trunk@63050 13f79535-47bb-0310-9956-ffa450edef68

1 files changed, 20 insertions, 0 deletions

diff --git a/include/apr_global_mutex.h b/include/apr_global_mutex.h
index 56e39bad4..fc5a0b3b6 100644
--- a/include/apr_global_mutex.h
+++ b/include/apr_global_mutex.h
@@ -75,6 +75,8 @@ extern "C" {
  * @{
  */
 
+#if !APR_PROC_MUTEX_IS_GLOBAL || defined(DOXYGEN)
+
 typedef struct apr_global_mutex_t apr_global_mutex_t;
 
 /*   Function definitions */
@@ -157,6 +159,24 @@ APR_DECLARE(apr_status_t) apr_global_mutex_destroy(apr_global_mutex_t *mutex);
  */
 APR_POOL_DECLARE_ACCESSOR(global_mutex);
 
+#else /* APR_PROC_MUTEX_IS_GLOBAL */
+
+/* Some platforms [e.g. Win32] have cross process locks that are truly
+ * global locks, since there isn't the concept of cross-process locks.
+ * Define these platforms in terms of an apr_proc_mutex_t.
+ */
+
+#define apr_global_mutex_t          apr_proc_mutex_t
+#define apr_global_mutex_create     apr_proc_mutex_create
+#define apr_global_mutex_child_init apr_proc_mutex_child_init
+#define apr_global_mutex_lock       apr_proc_mutex_lock
+#define apr_global_mutex_trylock    apr_proc_mutex_trylock
+#define apr_global_mutex_unlock     apr_proc_mutex_unlock
+#define apr_global_mutex_destroy    apr_proc_mutex_destroy
+#define apr_global_mutex_pool_get   apr_proc_mutex_pool_get
+
+#endif
+
 #ifdef __cplusplus
 }
 #endif