From: <[EMAIL PROTECTED]>
Sent: Tuesday, February 19, 2002 2:51 PM
> stoddard 02/02/19 12:51:35
>
> Modified: locks/win32 global_mutex.c
> . CHANGES libapr.dsp apr.dsp
> Log:
> Implement apr_global_mutex_foo() on Windows. This is basically identical
> to apr_proc_lock as a Windows MUTEX locks threads as well as processes.
This patch is right [working on the same] but the extra call and return
seems like a needless drain. What about simply this for Win32, and OS2, Netware
and whomever else doesn't need the distinction between cross-proc and global...
Index: include/apr_global_mutex.h
===================================================================
RCS file: /home/cvs/apr/include/apr_global_mutex.h,v
retrieving revision 1.1
diff -u -r1.1 apr_global_mutex.h
--- include/apr_global_mutex.h 18 Feb 2002 01:16:03 -0000 1.1
+++ include/apr_global_mutex.h 19 Feb 2002 21:17:31 -0000
@@ -75,6 +75,8 @@
* @{
*/
+#if !defined(WIN32) || defined(DOXYGEN)
+
typedef struct apr_global_mutex_t apr_global_mutex_t;
/* Function definitions */
@@ -156,6 +158,24 @@
* @return apr_pool_t the pool
*/
APR_POOL_DECLARE_ACCESSOR(global_mutex);
+
+#else
+
+/* 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
}
