You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@apr.apache.org by bn...@apache.org on 2002/02/20 20:58:57 UTC
cvs commit: apr/locks/netware global_mutex.c
bnicholes 02/02/20 11:58:57
Modified: build nw_export.inc
locks/netware global_mutex.c
Log:
Implementation of the global mutex APIs
Revision Changes Path
1.3 +1 -0 apr/build/nw_export.inc
Index: nw_export.inc
===================================================================
RCS file: /home/cvs/apr/build/nw_export.inc,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- nw_export.inc 29 Jan 2002 00:17:38 -0000 1.2
+++ nw_export.inc 20 Feb 2002 19:58:57 -0000 1.3
@@ -17,6 +17,7 @@
#include "apr_fnmatch.h"
#include "apr_general.h"
#include "apr_getopt.h"
+#include "apr_global_mutex.h"
#include "apr_hash.h"
#include "apr_inherit.h"
#include "apr_lib.h"
1.3 +30 -6 apr/locks/netware/global_mutex.c
Index: global_mutex.c
===================================================================
RCS file: /home/cvs/apr/locks/netware/global_mutex.c,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- 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;
}
APR_DECLARE(apr_status_t) apr_global_mutex_child_init(
@@ -68,27 +84,35 @@
const char *fname,
apr_pool_t *pool)
{
- return APR_ENOTIMPL;
+ return APR_SUCCESS;
}
APR_DECLARE(apr_status_t) apr_global_mutex_lock(apr_global_mutex_t *mutex)
{
- return APR_ENOTIMPL;
+ if (mutex)
+ return apr_thread_mutex_lock(mutex->mutex);
+ return APR_ENOLOCK;
}
APR_DECLARE(apr_status_t) apr_global_mutex_trylock(apr_global_mutex_t *mutex)
{
- return APR_ENOTIMPL;
+ if (mutex)
+ return apr_thread_mutex_trylock(mutex->mutex);
+ return APR_ENOLOCK;
}
APR_DECLARE(apr_status_t) apr_global_mutex_unlock(apr_global_mutex_t *mutex)
{
- return APR_ENOTIMPL;
+ if (mutex)
+ return apr_thread_mutex_unlock(mutex->mutex);
+ return APR_ENOLOCK;
}
APR_DECLARE(apr_status_t) apr_global_mutex_destroy(apr_global_mutex_t *mutex)
{
- return APR_ENOTIMPL;
+ if (mutex)
+ return apr_thread_mutex_destroy(mutex->mutex);
+ return APR_ENOLOCK;
}
APR_POOL_IMPLEMENT_ACCESSOR(global_mutex)
Re: cvs commit: apr/locks/netware global_mutex.c
Posted by Aaron Bannert <aa...@clove.org>.
On Wed, Feb 20, 2002 at 06:44:25PM -0600, William Rowe wrote:
> Now how are you going to avoid calling apr_foo_mutex_create calling
> apr_bar_mutex_create without 1. duplicating code, or 2. exposing the
> synonyms to the client code [via apr/include/apr_foo_mutex.h"] ?
>
> Either we have an extra call setup/teardown in mutexing code [already time
> sensitive] or we have APR_HAS_FOO_IS_BAR_MUTEX-style declarations
> in apr.[h.in|.hw.|.nw] that feed our apr_foo_mutex.h header.
Yes, you're right, and I don't see any way around it. I am still
hung up on the feeling that we are exposing an implementation detail.
What I mean by "implementation detail" is this is not a macro that
we want to encourage app authors to use, in the way they might want
to use APR_HAS_THREADS, for example. They should never use an
APR_PROC_MUTEX_IS_GLOBAL to change the way their code compiles.
-aaron
Re: cvs commit: apr/locks/netware global_mutex.c
Posted by "William A. Rowe, Jr." <wr...@covalent.net>.
From: "Aaron Bannert" <aa...@clove.org>
Sent: Wednesday, February 20, 2002 6:32 PM
> On Wed, Feb 20, 2002 at 06:23:05PM -0600, William Rowe wrote:
> > > An alternative would be to #define APR_PROC_MUTEX_IS_GLOBAL
> > > in the include/arch/<foo>/proc_mutex.h and let that dictate how
> > > global_mutex.c is implemented per platform (or in the default impl.).
>
> I did provide an alternative solution, which I think is more like what
> you were talking about but doesn't require a #define in apr.h.
What does something in the private arch/ tree have to do with eliminating a
call stack layer that isn't required.
#define apr_foo_mutex_t apr_bar_mutex_t
#define apr_foo_mutex_create apr_bar_mutex_create
client's code...
#include "apr_foo_mutex.h"
...
{
apr_foo_mutex_t *p;
rv = apr_foo_mutex_create(...)
Now how are you going to avoid calling apr_foo_mutex_create calling
apr_bar_mutex_create without 1. duplicating code, or 2. exposing the
synonyms to the client code [via apr/include/apr_foo_mutex.h"] ?
Either we have an extra call setup/teardown in mutexing code [already time
sensitive] or we have APR_HAS_FOO_IS_BAR_MUTEX-style declarations
in apr.[h.in|.hw.|.nw] that feed our apr_foo_mutex.h header.
Bill
Re: cvs commit: apr/locks/netware global_mutex.c
Posted by Aaron Bannert <aa...@clove.org>.
On Wed, Feb 20, 2002 at 06:23:05PM -0600, William Rowe wrote:
> > These are implementation details, so I don't see why they need to be
> > defined globally (in apr.h, if I'm understanding you correctly). I do
> > agree, however, that the extra function call is unnecessary. Can we use
> > APR_INLINE? An alternative would be to #define APR_PROC_MUTEX_IS_GLOBAL
> > in the include/arch/<foo>/proc_mutex.h and let that dictate how
> > global_mutex.c is implemented per platform (or in the default impl.).
>
> Name, please, one place where APR_INLINE actually inlines squat today.
It was merely a suggestion. I don't have any idea of APR_INLINE actually
works.
I did provide an alternative solution, which I think is more like what
you were talking about but doesn't require a #define in apr.h.
-aaron
Re: cvs commit: apr/locks/netware global_mutex.c
Posted by "William A. Rowe, Jr." <wr...@covalent.net>.
From: "Aaron Bannert" <aa...@clove.org>
Sent: Wednesday, February 20, 2002 4:13 PM
> On Wed, Feb 20, 2002 at 02:27:37PM -0600, William Rowe wrote:
> >
> > 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).
>
> These are implementation details, so I don't see why they need to be
> defined globally (in apr.h, if I'm understanding you correctly). I do
> agree, however, that the extra function call is unnecessary. Can we use
> APR_INLINE? An alternative would be to #define APR_PROC_MUTEX_IS_GLOBAL
> in the include/arch/<foo>/proc_mutex.h and let that dictate how
> global_mutex.c is implemented per platform (or in the default impl.).
Name, please, one place where APR_INLINE actually inlines squat today.
Re: cvs commit: apr/locks/netware global_mutex.c
Posted by Aaron Bannert <aa...@clove.org>.
On Wed, Feb 20, 2002 at 02:27:37PM -0600, William Rowe wrote:
> 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 :)
+1 (OOM is not a portable condition)
> 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).
These are implementation details, so I don't see why they need to be
defined globally (in apr.h, if I'm understanding you correctly). I do
agree, however, that the extra function call is unnecessary. Can we use
APR_INLINE? An alternative would be to #define APR_PROC_MUTEX_IS_GLOBAL
in the include/arch/<foo>/proc_mutex.h and let that dictate how
global_mutex.c is implemented per platform (or in the default impl.).
-aaron
Re: cvs commit: apr/locks/netware global_mutex.c
Posted by "William A. Rowe, Jr." <wr...@covalent.net>.
> 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
Re: cvs commit: apr/locks/netware global_mutex.c
Posted by "William A. Rowe, Jr." <wr...@covalent.net>.
> 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