apr-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brad Nicholes" <BNICHO...@novell.com>
Subject Re: cvs commit: apr/locks/netware global_mutex.c
Date Wed, 20 Feb 2002 20:50:26 GMT
I agree 100%.  In fact when I implemented both global_mutex and
proc_mutex for NetWare it bothered me that I was just duplicating code. 
For NetWare there is really only one kind of mutex because all resources
are shared.  Therefore for us a global mutex is a proc mutex is a thread
mutex.  I don't know if  makes much sense on other platforms, but for
NetWare I would like to see the proposal taken one step further with
APR_PROC_MUTEX_IS_THREAD_MUTEX

Brad

Brad Nicholes
Senior Software Engineer
Novell, Inc., a leading provider of Net business solutions
http://www.novell.com 

>>> wrowe@covalent.net Wednesday, February 20, 2002 1:27:37 PM >>>
> bnicholes    02/02/20 11:58:57
> 
>   Modified:    build    nw_export.inc
>                locks/netware global_mutex.c
>   Log:
>   Implementation of the global mutex APIs
>   
>   --- global_mutex.c 18 Feb 2002 13:06:43 -0000 1.2
>   +++ global_mutex.c 20 Feb 2002 19:58:57 -0000 1.3
>   @@ -54,13 +54,29 @@
>    
>    #include "apr.h"
>    #include "apr_strings.h"
>   +#include "global_mutex.h"
>   +#include "apr_thread_mutex.h"
>    
>    APR_DECLARE(apr_status_t)
apr_global_mutex_create(apr_global_mutex_t **mutex,
>                                                      const char
*fname,
>                                                      apr_lockmech_e
mech,
>                                                      apr_pool_t
*pool)
>    {
>   -    return APR_ENOTIMPL;
>   +    apr_status_t ret;
>   +    apr_global_mutex_t *new_mutex = NULL;
>   +    new_mutex = (apr_global_mutex_t *)apr_pcalloc(pool,
sizeof(apr_global_mutex_t));
>   + 
>   + if(new_mutex ==NULL) {
>   +        return APR_ENOMEM;
>   +    }     
>   +    
>   +    new_mutex->pool = pool;
>   +    ret = apr_thread_mutex_create(&(new_mutex->mutex),
APR_THREAD_MUTEX_DEFAULT, pool);
>   +
>   +    if (ret == APR_SUCCESS)
>   +        *mutex = new_mutex;
>   +
>   +    return ret;

What's gotten into this list lately :-?  apr_p[c]alloc() always
succeeds or we fault ...
we do _not_ test p[c]alloc throughout the code :)

And, if I can ask, what is the problem with returning apr_thread_mutex
results, and letting
apr_thread_mutex do the work [of allocation]?

The more I consider the win32 fix, this netware and the coming BeOS
fix, I believe we need
two symbols;

APR_GLOBAL_MUTEX_IS_THREAD_MUTEX

and

APR_GLOBAL_MUTEX_IS_PROC_MUTEX

and pull off all the magic in apr_global.h.  Unless threadproc [global]
mutexes are custom,
it seems Win32/OS2 can simply use defines to apr_proc_mutex
(APR_GLOBAL_MUTEX_IS_PROC_MUTEX), 
while Netware and BeOS can simply use apr_thread_mutex
(APR_GLOBAL_MUTEX_IS_THREAD_MUTEX).

Unless there is huge disagreement, I'll commit such a change myself. 
[OS2/BeOS will need
the appropriate changes to apr.h.in, while I can easily fix apr.nw and
apr.hw.]

Bill


Mime
View raw message