You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by "William A. Rowe, Jr." <wr...@covalent.net> on 2002/02/19 22:16:59 UTC
Re: cvs commit: apr CHANGES libapr.dsp apr.dsp
From: <st...@apache.org>
Sent: Tuesday, February 19, 2002 2:51 PM
> stoddard 02/02/19 12:51:35
>
> Modified: locks/win32 global_mutex.c
> . CHANGES libapr.dsp apr.dsp
> Log:
> Implement apr_global_mutex_foo() on Windows. This is basically identical
> to apr_proc_lock as a Windows MUTEX locks threads as well as processes.
This patch is right [working on the same] but the extra call and return
seems like a needless drain. What about simply this for Win32, and OS2, Netware
and whomever else doesn't need the distinction between cross-proc and global...
Index: include/apr_global_mutex.h
===================================================================
RCS file: /home/cvs/apr/include/apr_global_mutex.h,v
retrieving revision 1.1
diff -u -r1.1 apr_global_mutex.h
--- include/apr_global_mutex.h 18 Feb 2002 01:16:03 -0000 1.1
+++ include/apr_global_mutex.h 19 Feb 2002 21:17:31 -0000
@@ -75,6 +75,8 @@
* @{
*/
+#if !defined(WIN32) || defined(DOXYGEN)
+
typedef struct apr_global_mutex_t apr_global_mutex_t;
/* Function definitions */
@@ -156,6 +158,24 @@
* @return apr_pool_t the pool
*/
APR_POOL_DECLARE_ACCESSOR(global_mutex);
+
+#else
+
+/* Some platforms [e.g. Win32] have cross process locks that are truly
+ * global locks, since there isn't the concept of cross-process locks
+ * Define these platforms in terms of an apr_proc_mutex_t.
+ */
+
+#define apr_global_mutex_t apr_proc_mutex_t
+#define apr_global_mutex_create apr_proc_mutex_create
+#define apr_global_mutex_child_init apr_proc_mutex_child_init
+#define apr_global_mutex_lock apr_proc_mutex_lock
+#define apr_global_mutex_trylock apr_proc_mutex_trylock
+#define apr_global_mutex_unlock apr_proc_mutex_unlock
+#define apr_global_mutex_destroy apr_proc_mutex_destroy
+#define apr_global_mutex_pool_get apr_proc_mutex_pool_get
+
+#endif
#ifdef __cplusplus
}
Re: cvs commit: apr CHANGES libapr.dsp apr.dsp
Posted by "William A. Rowe, Jr." <wr...@covalent.net>.
From: "Bill Stoddard" <bi...@wstoddard.com>
Sent: Tuesday, February 19, 2002 3:31 PM
> I considered this but in the interest of keeping the code squeaky clean, decided
> otherwise. I don't object to your solution, though others might. I can go either way...
And I had considered the apr_global_mutex_t and apr_proc_mutex_t pointers, and the
advantage of keeping them unrelated [but figured 95% of possible mistakes would be
picked up on another platform.] I could fall either way as well... We can wait and
see if others have any comments.
Bill
> >
> > /* Function definitions */
> > @@ -156,6 +158,24 @@
> > * @return apr_pool_t the pool
> > */
> > APR_POOL_DECLARE_ACCESSOR(global_mutex);
> > +
> > +#else
> > +
> > +/* Some platforms [e.g. Win32] have cross process locks that are truly
> > + * global locks, since there isn't the concept of cross-process locks
> > + * Define these platforms in terms of an apr_proc_mutex_t.
> > + */
> > +
> > +#define apr_global_mutex_t apr_proc_mutex_t
> > +#define apr_global_mutex_create apr_proc_mutex_create
> > +#define apr_global_mutex_child_init apr_proc_mutex_child_init
> > +#define apr_global_mutex_lock apr_proc_mutex_lock
> > +#define apr_global_mutex_trylock apr_proc_mutex_trylock
> > +#define apr_global_mutex_unlock apr_proc_mutex_unlock
> > +#define apr_global_mutex_destroy apr_proc_mutex_destroy
> > +#define apr_global_mutex_pool_get apr_proc_mutex_pool_get
> > +
> > +#endif
> >
> > #ifdef __cplusplus
> > }
> >
> >
>
>
Re: cvs commit: apr CHANGES libapr.dsp apr.dsp
Posted by Bill Stoddard <bi...@wstoddard.com>.
I considered this but in the interest of keeping the code squeaky clean, decided
otherwise. I don't object to your solution, though others might. I can go either way...
Bill
----- Original Message -----
From: "William A. Rowe, Jr." <wr...@covalent.net>
To: <de...@apr.apache.org>; <ap...@apache.org>
Sent: Tuesday, February 19, 2002 4:16 PM
Subject: Re: cvs commit: apr CHANGES libapr.dsp apr.dsp
> From: <st...@apache.org>
> Sent: Tuesday, February 19, 2002 2:51 PM
>
>
> > stoddard 02/02/19 12:51:35
> >
> > Modified: locks/win32 global_mutex.c
> > . CHANGES libapr.dsp apr.dsp
> > Log:
> > Implement apr_global_mutex_foo() on Windows. This is basically identical
> > to apr_proc_lock as a Windows MUTEX locks threads as well as processes.
>
> This patch is right [working on the same] but the extra call and return
> seems like a needless drain. What about simply this for Win32, and OS2, Netware
> and whomever else doesn't need the distinction between cross-proc and global...
>
> Index: include/apr_global_mutex.h
> ===================================================================
> RCS file: /home/cvs/apr/include/apr_global_mutex.h,v
> retrieving revision 1.1
> diff -u -r1.1 apr_global_mutex.h
> --- include/apr_global_mutex.h 18 Feb 2002 01:16:03 -0000 1.1
> +++ include/apr_global_mutex.h 19 Feb 2002 21:17:31 -0000
> @@ -75,6 +75,8 @@
> * @{
> */
>
> +#if !defined(WIN32) || defined(DOXYGEN)
> +
> typedef struct apr_global_mutex_t apr_global_mutex_t;
>
> /* Function definitions */
> @@ -156,6 +158,24 @@
> * @return apr_pool_t the pool
> */
> APR_POOL_DECLARE_ACCESSOR(global_mutex);
> +
> +#else
> +
> +/* Some platforms [e.g. Win32] have cross process locks that are truly
> + * global locks, since there isn't the concept of cross-process locks
> + * Define these platforms in terms of an apr_proc_mutex_t.
> + */
> +
> +#define apr_global_mutex_t apr_proc_mutex_t
> +#define apr_global_mutex_create apr_proc_mutex_create
> +#define apr_global_mutex_child_init apr_proc_mutex_child_init
> +#define apr_global_mutex_lock apr_proc_mutex_lock
> +#define apr_global_mutex_trylock apr_proc_mutex_trylock
> +#define apr_global_mutex_unlock apr_proc_mutex_unlock
> +#define apr_global_mutex_destroy apr_proc_mutex_destroy
> +#define apr_global_mutex_pool_get apr_proc_mutex_pool_get
> +
> +#endif
>
> #ifdef __cplusplus
> }
>
>