Jim Jagielski wrote:
>
> Why is this a no-op? We don't even try to call apr_proc_mutex_child_init
> which causes trouble for those apps which use apr_global and have
> a proc_child_init which does something (ala flock)!
>
Could a few more eyes look at this... my brain is fried right now :)
Index: locks/unix/global_mutex.c
===================================================================
RCS file: /home/cvs/apr/locks/unix/global_mutex.c,v
retrieving revision 1.10
diff -u -r1.10 global_mutex.c
--- locks/unix/global_mutex.c 6 Jan 2003 23:44:31 -0000 1.10
+++ locks/unix/global_mutex.c 29 Mar 2003 03:04:51 -0000
@@ -121,7 +121,10 @@
const char *fname,
apr_pool_t *pool)
{
- return APR_SUCCESS;
+ apr_status_t rv;
+
+ rv = apr_proc_mutex_child_init(&((*mutex)->proc_mutex), fname, pool);
+ return rv;
}
APR_DECLARE(apr_status_t) apr_global_mutex_lock(apr_global_mutex_t *mutex)
--
===========================================================================
Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/
"A society that will trade a little liberty for a little order
will lose both and deserve neither" - T.Jefferson
