> 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
