Return-Path: Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 85252 invoked by uid 500); 20 Feb 2002 20:50:32 -0000 Mailing-List: contact dev-help@apr.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Delivered-To: mailing list dev@apr.apache.org Received: (qmail 85225 invoked from network); 20 Feb 2002 20:50:31 -0000 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.0.1 Date: Wed, 20 Feb 2002 13:50:26 -0700 From: "Brad Nicholes" To: ,, Subject: Re: cvs commit: apr/locks/netware global_mutex.c Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Rating: daedalus.apache.org 1.6.2 500/1000/N 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