From: Aaron Bannert <aaron@apache.org>
Date: Fri, 16 Nov 2001 18:28:25 +0000 (+0000)
Subject: Conversion from old apr_lock_t to new apr_thread_mutex_t
X-Git-Url: https://granicus.if.org/sourcecode?a=commitdiff_plain;h=ad227d0e64415eab6561b93506cbb87d9d01715e;p=apache

Conversion from old apr_lock_t to new apr_thread_mutex_t
(only converting INTRAPROCESS locks at this time).

I don't see how this used to work, which also means I'm not entirely
sure if it works now. It really didn't look like it was allocating
the correct size before. It compiles and SSL still works in my limited
tests, but I'd appreciate a second opinion.


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@91979 13f79535-47bb-0310-9956-ffa450edef68
---

diff --git a/modules/ssl/ssl_util.c b/modules/ssl/ssl_util.c
index 59b0b62233..ab3b55617c 100644
--- a/modules/ssl/ssl_util.c
+++ b/modules/ssl/ssl_util.c
@@ -61,6 +61,8 @@
                                   name to the list of people
                                   who piss me off!''
                                             -- Calvin          */
+#include <apr_thread_mutex.h>
+
 #include "mod_ssl.h"
 #include "ap_mpm.h"
 
@@ -336,17 +338,17 @@ SSLModConfigRec *ssl_util_getmodconfig_ssl(SSL *ssl, const char *key)
  * To ensure thread-safetyness in OpenSSL - work in progress
  */
 
-static apr_lock_t *lock_cs[CRYPTO_NUM_LOCKS];
-static long        lock_count[CRYPTO_NUM_LOCKS];
+static apr_thread_mutex_t **lock_cs;
+static long                 lock_count[CRYPTO_NUM_LOCKS];
 
 static void ssl_util_thr_lock(int mode, int type, const char *file, int line)
 {
     if (mode & CRYPTO_LOCK) {
-        apr_lock_acquire(lock_cs[type]);
+        apr_thread_mutex_lock(lock_cs[type]);
         lock_count[type]++;
     }
     else {
-        apr_lock_release(lock_cs[type]);
+        apr_thread_mutex_unlock(lock_cs[type]);
     }
 }
 
@@ -364,7 +366,7 @@ static apr_status_t ssl_util_thread_cleanup(void *data)
     CRYPTO_set_locking_callback(NULL);
 
     for (i = 0; i < CRYPTO_NUM_LOCKS; i++) {
-        apr_lock_destroy(lock_cs[i]);
+        apr_thread_mutex_destroy(lock_cs[i]);
     }
 
     return APR_SUCCESS;
@@ -373,7 +375,9 @@ static apr_status_t ssl_util_thread_cleanup(void *data)
 void ssl_util_thread_setup(server_rec *s, apr_pool_t *p)
 {
     int i, threaded_mpm;
+    /* This variable is not used? -aaron
     SSLModConfigRec *mc = myModConfig(s);
+    */
 
     ap_mpm_query(AP_MPMQ_IS_THREADED, &threaded_mpm);
 
@@ -381,7 +385,7 @@ void ssl_util_thread_setup(server_rec *s, apr_pool_t *p)
         return;
     }
 
-    *lock_cs = apr_palloc(p, CRYPTO_NUM_LOCKS);
+    lock_cs = apr_palloc(p, CRYPTO_NUM_LOCKS * sizeof(apr_thread_mutex_t *));
 
     /*
      * XXX: CRYPTO_NUM_LOCKS == 28
@@ -389,9 +393,10 @@ void ssl_util_thread_setup(server_rec *s, apr_pool_t *p)
      * for example: debug_malloc, debug_malloc2 (see crypto/cryptlib.c)
      */
     for (i = 0; i < CRYPTO_NUM_LOCKS; i++) {
-        lock_count[i]=0;
-        apr_lock_create(&(lock_cs[i]), APR_MUTEX, APR_INTRAPROCESS,
-                        mc->szMutexFile, p);
+        lock_count[i] = 0;
+        /* XXX: Can we remove the lock_count now that apr_thread_mutex_t
+         * can support nested (aka recursive) locks? -aaron */
+        apr_thread_mutex_create(&(lock_cs[i]), APR_THREAD_MUTEX_DEFAULT, p);
     }
 
 #if APR_HAS_THREADS