httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1)" <madhusudan_mathiha...@hp.com>
Subject RE: cvs commit: httpd-2.0/modules/ssl README mod_ssl.h ssl_engine _init.c ssl_util.c
Date Fri, 24 Aug 2001 06:15:44 GMT
Hi,
  I'd missed out the CRYPRO_thread_id stuff in my earlier patch .. Here it
comes :
Index: ssl_util.c
===================================================================
RCS file: /home/cvspublic/httpd-2.0/modules/ssl/ssl_util.c,v
retrieving revision 1.14
diff -u -r1.14 ssl_util.c
--- ssl_util.c  2001/08/24 05:31:51     1.14
+++ ssl_util.c  2001/08/24 06:04:08
@@ -336,8 +336,7 @@
 static apr_lock_t *lock_cs[CRYPTO_NUM_LOCKS];
 static long        lock_count[CRYPTO_NUM_LOCKS];
 
-static void ssl_util_thread_locking_callback(int mode, int type,
-                                             const char *file, int line)
+static void ssl_util_thr_lock(int mode, int type, char *file, int line)
 {
     if (mode & CRYPTO_LOCK) {
         apr_lock_acquire(lock_cs[type]);
@@ -348,6 +347,11 @@
     }
 }
 
+static unsigned long ssl_util_thr_id()
+{
+    return (unsigned long) apr_os_thread_current();
+}
+
 static apr_status_t ssl_util_thread_cleanup(void *data)
 {
     int i;
@@ -385,7 +389,8 @@
                         mc->szMutexFile, p);
     }
 
-    CRYPTO_set_locking_callback(ssl_util_thread_locking_callback);
+    CRYPTO_set_id_callback(ssl_util_thr_id);
+    CRYPTO_set_locking_callback((void (*)())ssl_util_thr_lock);
 
     apr_pool_cleanup_register(p, NULL,
                               ssl_util_thread_cleanup,




Thanks
-Madhu




-----Original Message-----
From: Doug MacEachern
To: dev@httpd.apache.org
Sent: 8/23/01 11:08 PM
Subject: Re: cvs commit: httpd-2.0/modules/ssl README mod_ssl.h
ssl_engine_init.c ssl_util.c

On Thu, 23 Aug 2001, Justin Erenkrantz wrote:
 
> If you created the locks as INTRAPROCESS before fork()ing new
children, 
> would each children's copy of the lock be isolated?  Maybe.  If so, 
> then the post_config hook works, but I think child_init makes a bit 
> more sense.  But, that's me.  -- justin

there must be other intraprocess locks created at startup time, i'd be
surprised if there's an issue.  one problem with using child init is
that
not all mpms support it, notice theres a few missing:
% find . -name "*.c" | xargs grep ap_run_child_init 
./server/mpm/perchild/perchild.c:    ap_run_child_init(pchild,
ap_server_conf);
./server/mpm/prefork/prefork.c:    ap_run_child_init(pchild,
ap_server_conf);
./server/mpm/spmt_os2/spmt_os2.c:    ap_run_child_init(pchild,
ap_server_conf);
./server/mpm/threaded/threaded.c:    ap_run_child_init(pchild,
ap_server_conf);
./server/mpm/worker/worker.c:    ap_run_child_init(pchild,
ap_server_conf);

Mime
View raw message