You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Jeff Trawick <tr...@attglobal.net> on 2001/06/25 22:30:45 UTC
[PATCH] allow an APR app to choose underlying lock mechanism
(on Unix, at least)
Brain-dead changes are needed for win32, beos, and os2 to ensure that
the new parameter to apr_lock_create() is reasonable. I'll do it; I
just haven't done it yet.
Only the mechanism for interprocess lock can be chosen at the moment.
We can add that later if/when it is necessary or we can build in the
interface now. I don't care, but please suggest an interface if you
want it to be in place immediately.
I've changed Apache and standard modules too and manually tweaked prefork
and threaded to tell APR to use various lock mechanisms, but I haven't
done any work to add any sort of configuration option to the MPMs.
The Apache patch isn't posted anywhere because it is just more of the
same stuff seen below.
Did anybody want this done differently?
Index: file_io/unix/filedup.c
===================================================================
RCS file: /home/cvs/apr/file_io/unix/filedup.c,v
retrieving revision 1.29
diff -u -r1.29 filedup.c
--- file_io/unix/filedup.c 2001/02/16 04:15:37 1.29
+++ file_io/unix/filedup.c 2001/06/25 20:25:48
@@ -80,8 +80,8 @@
(*new_file)->buffered = old_file->buffered;
if ((*new_file)->buffered) {
#if APR_HAS_THREADS
- apr_lock_create(&((*new_file)->thlock), APR_MUTEX, APR_INTRAPROCESS, NULL,
- p);
+ apr_lock_create(&((*new_file)->thlock), APR_MUTEX, APR_INTRAPROCESS,
+ APR_LOCK_DEFAULT, NULL, p);
#endif
(*new_file)->buffer = apr_palloc(p, APR_FILE_BUFSIZE);
}
Index: file_io/unix/open.c
===================================================================
RCS file: /home/cvs/apr/file_io/unix/open.c,v
retrieving revision 1.76
diff -u -r1.76 open.c
--- file_io/unix/open.c 2001/06/07 14:32:15 1.76
+++ file_io/unix/open.c 2001/06/25 20:25:48
@@ -115,7 +115,7 @@
(*new)->buffer = apr_palloc(cont, APR_FILE_BUFSIZE);
#if APR_HAS_THREADS
rv = apr_lock_create(&((*new)->thlock), APR_MUTEX, APR_INTRAPROCESS,
- NULL, cont);
+ APR_LOCK_DEFAULT, NULL, cont);
if (rv) {
return rv;
}
Index: include/apr_lock.h
===================================================================
RCS file: /home/cvs/apr/include/apr_lock.h,v
retrieving revision 1.27
diff -u -r1.27 apr_lock.h
--- include/apr_lock.h 2001/06/06 18:11:02 1.27
+++ include/apr_lock.h 2001/06/25 20:26:01
@@ -71,6 +71,9 @@
typedef enum {APR_MUTEX, APR_READWRITE} apr_locktype_e;
+typedef enum {APR_LOCK_FCNTL, APR_LOCK_FLOCK, APR_LOCK_SYSVSEM, APR_LOCK_PROC_PTHREAD,
+ APR_LOCK_DEFAULT} apr_lockmech_e;
+
typedef enum {APR_READER, APR_WRITER} apr_readerwriter_e;
typedef struct apr_lock_t apr_lock_t;
@@ -92,6 +95,15 @@
* APR_LOCKALL lock processes and threads from the
* protected area.
* </PRE>
+ * @param mech The mechanism to use for interprocess locks, if available on
+ * the platform; one of:
+ * <PRE>
+ * APR_LOCK_FCNTL
+ * APR_LOCK_FLOCK
+ * APR_LOCK_SYSVSEM
+ * APR_LOCK_PROC_PTHREAD
+ * APR_LOCK_DEFAULT (APR chooses the mechanism)
+ * </PRE>
* @param fname A file name to use if the lock mechanism requires one. This
* argument should always be provided. The lock code itself will
* determine if it should be used.
@@ -103,6 +115,7 @@
APR_DECLARE(apr_status_t) apr_lock_create(apr_lock_t **lock,
apr_locktype_e type,
apr_lockscope_e scope,
+ apr_lockmech_e mech,
const char *fname,
apr_pool_t *pool);
Index: lib/apr_pools.c
===================================================================
RCS file: /home/cvs/apr/lib/apr_pools.c,v
retrieving revision 1.98
diff -u -r1.98 apr_pools.c
--- lib/apr_pools.c 2001/06/13 16:10:18 1.98
+++ lib/apr_pools.c 2001/06/25 20:26:20
@@ -806,13 +806,13 @@
#endif
#if APR_HAS_THREADS
status = apr_lock_create(&alloc_mutex, APR_MUTEX, APR_INTRAPROCESS,
- NULL, globalp);
+ APR_LOCK_DEFAULT, NULL, globalp);
if (status != APR_SUCCESS) {
apr_lock_destroy(alloc_mutex);
return status;
}
status = apr_lock_create(&spawn_mutex, APR_MUTEX, APR_INTRAPROCESS,
- NULL, globalp);
+ APR_LOCK_DEFAULT, NULL, globalp);
if (status != APR_SUCCESS) {
apr_lock_destroy(spawn_mutex);
return status;
Index: locks/unix/locks.c
===================================================================
RCS file: /home/cvs/apr/locks/unix/locks.c,v
retrieving revision 1.55
diff -u -r1.55 locks.c
--- locks/unix/locks.c 2001/06/25 20:23:16 1.55
+++ locks/unix/locks.c 2001/06/25 20:26:30
@@ -126,11 +126,38 @@
};
#endif
-static apr_status_t create_lock(apr_lock_t *new, const char *fname)
+static apr_status_t choose_method(apr_lock_t *new, apr_lockmech_e mech)
{
- apr_status_t stat;
-
- if (new->scope != APR_INTRAPROCESS) {
+ switch (mech) {
+ case APR_LOCK_FCNTL:
+#if APR_HAS_FCNTL_SERIALIZE
+ new->inter_meth = &apr_unix_fcntl_methods;
+#else
+ return APR_ENOTIMPL;
+#endif
+ break;
+ case APR_LOCK_FLOCK:
+#if APR_HAS_FLOCK_SERIALIZE
+ new->inter_meth = &apr_unix_flock_methods;
+#else
+ return APR_ENOTIMPL;
+#endif
+ break;
+ case APR_LOCK_SYSVSEM:
+#if APR_HAS_SYSVSEM_SERIALIZE
+ new->inter_meth = &apr_unix_sysv_methods;
+#else
+ return APR_ENOTIMPL;
+#endif
+ break;
+ case APR_LOCK_PROC_PTHREAD:
+#if APR_HAS_PROC_PTHREAD_SERIALIZE
+ new->inter_meth = &apr_unix_proc_pthread_methods;
+#else
+ return APR_ENOTIMPL;
+#endif
+ break;
+ case APR_LOCK_DEFAULT:
#if APR_USE_FLOCK_SERIALIZE
new->inter_meth = &apr_unix_flock_methods;
#elif APR_USE_SYSVSEM_SERIALIZE
@@ -142,6 +169,21 @@
#else
return APR_ENOTIMPL;
#endif
+ break;
+ default:
+ return APR_ENOTIMPL;
+ }
+ return APR_SUCCESS;
+}
+
+static apr_status_t create_lock(apr_lock_t *new, apr_lockmech_e mech, const char *fname)
+{
+ apr_status_t stat;
+
+ if (new->scope != APR_INTRAPROCESS) {
+ if ((stat = choose_method(new, mech)) != APR_SUCCESS) {
+ return stat;
+ }
}
if (new->scope != APR_CROSS_PROCESS) {
@@ -190,8 +232,8 @@
}
apr_status_t apr_lock_create(apr_lock_t **lock, apr_locktype_e type,
- apr_lockscope_e scope, const char *fname,
- apr_pool_t *pool)
+ apr_lockscope_e scope, apr_lockmech_e mech,
+ const char *fname, apr_pool_t *pool)
{
apr_lock_t *new;
apr_status_t stat;
@@ -202,7 +244,7 @@
new->type = type;
new->scope = scope;
- if ((stat = create_lock(new, fname)) != APR_SUCCESS)
+ if ((stat = create_lock(new, mech, fname)) != APR_SUCCESS)
return stat;
*lock = new;
Index: memory/unix/apr_sms.c
===================================================================
RCS file: /home/cvs/apr/memory/unix/apr_sms.c,v
retrieving revision 1.22
diff -u -r1.22 apr_sms.c
--- memory/unix/apr_sms.c 2001/06/13 01:35:47 1.22
+++ memory/unix/apr_sms.c 2001/06/25 20:26:37
@@ -220,8 +220,8 @@
apr_pool_create(&sms->pool, pms ? pms->pool : NULL);
/* Create the lock we'll use to protect cleanups and child lists */
- apr_lock_create(&sms->sms_lock, APR_MUTEX, APR_LOCKALL, NULL,
- sms->pool);
+ apr_lock_create(&sms->sms_lock, APR_MUTEX, APR_LOCKALL, APR_LOCK_DEFAULT,
+ NULL, sms->pool);
return APR_SUCCESS;
}
Index: memory/unix/apr_sms_tracking.c
===================================================================
RCS file: /home/cvs/apr/memory/unix/apr_sms_tracking.c,v
retrieving revision 1.13
diff -u -r1.13 apr_sms_tracking.c
--- memory/unix/apr_sms_tracking.c 2001/06/13 14:17:38 1.13
+++ memory/unix/apr_sms_tracking.c 2001/06/25 20:26:38
@@ -289,7 +289,7 @@
tms = (apr_sms_tracking_t *)new_sms;
tms->nodes = NULL;
- apr_lock_create(&tms->lock, APR_MUTEX, APR_LOCKALL, NULL,
+ apr_lock_create(&tms->lock, APR_MUTEX, APR_LOCKALL, APR_LOCK_DEFAULT, NULL,
new_sms->pool);
apr_sms_assert(new_sms);
Index: test/testlock.c
===================================================================
RCS file: /home/cvs/apr/test/testlock.c,v
retrieving revision 1.3
diff -u -r1.3 testlock.c
--- test/testlock.c 2001/06/06 22:25:43 1.3
+++ test/testlock.c 2001/06/25 20:27:22
@@ -143,7 +143,7 @@
printf("RW Lock Tests\n");
printf("%-60s", " Initializing the RW lock");
s1 = apr_lock_create(&thread_rw_lock, APR_READWRITE, APR_INTRAPROCESS,
- "lock.file", pool);
+ APR_LOCK_CREATE, "lock.file", pool);
if (s1 != APR_SUCCESS) {
printf("Failed!\n");
return s1;
@@ -191,7 +191,7 @@
printf("Exclusive lock test\n");
printf("%-60s", " Initializing the lock");
s1 = apr_lock_create(&thread_lock, APR_MUTEX, APR_INTRAPROCESS,
- "lock.file", pool);
+ APR_LOCK_CREATE, "lock.file", pool);
if (s1 != APR_SUCCESS) {
printf("Failed!\n");
@@ -239,8 +239,8 @@
printf("Testing multiple locking\n");
printf("%-60s"," Creating the lock we'll use");
- if ((rv = apr_lock_create(&multi, APR_MUTEX, APR_LOCKALL,"multi.lock",
- pool)) != APR_SUCCESS) {
+ if ((rv = apr_lock_create(&multi, APR_MUTEX, APR_LOCKALL,APR_LOCK_CREATE,
+ "multi.lock", pool)) != APR_SUCCESS) {
printf("Failed!\n");
return rv;
}
--
Jeff Trawick | trawick@attglobal.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: [PATCH] allow an APR app to choose underlying lock mechanism
Posted by Aaron Bannert <aa...@ebuilt.com>.
I think this looks great.
Do I have any support yet for a fully-separated locks API, something
to the effect of:
Inter/cross process locks handled by:
apr_lock_interprocess_*()
Intraprocess locks handled by (these could even be POSIX):
apr_lock_mutex_*()
apr_lock_cond_*()
apr_lock_rwlock_*()
...
(replace "*" above with each of {create, acquire, release, destroy, etc...})
I am expecting this kind of an API to work well with your changes below
(choosing the underlying lock mechanism).
Comments?
-aaron
On Mon, Jun 25, 2001 at 04:30:45PM -0400, Jeff Trawick wrote:
> (on Unix, at least)
>
> Brain-dead changes are needed for win32, beos, and os2 to ensure that
> the new parameter to apr_lock_create() is reasonable. I'll do it; I
> just haven't done it yet.
>
> Only the mechanism for interprocess lock can be chosen at the moment.
> We can add that later if/when it is necessary or we can build in the
> interface now. I don't care, but please suggest an interface if you
> want it to be in place immediately.
>
> I've changed Apache and standard modules too and manually tweaked prefork
> and threaded to tell APR to use various lock mechanisms, but I haven't
> done any work to add any sort of configuration option to the MPMs.
> The Apache patch isn't posted anywhere because it is just more of the
> same stuff seen below.
>
> Did anybody want this done differently?
Re: [PATCH] allow an APR app to choose underlying lock mechanism
Posted by Aaron Bannert <aa...@ebuilt.com>.
I attempted to propose a more elaborate form of this in one of my various
unclear messages. It may make more sense if we have two sets of function
calls (layers), one is the platform-independent stuff, and the other
is the platform-specific stuff. The former will most likely use the
latter, but both can be exposed for cases mentioned earlier in this thread.
(would it just be better if I posted a patch?)
-aaron
On Mon, Jun 25, 2001 at 07:30:51PM -0400, Jeff Trawick wrote:
> Here's an idea:
>
> Leave apr_lock_create() alone (though I think some other folks wanna
> muck with it :) ).
(ooh ooh! me! *waves hands* :) )
> Add apr_lock_create_np() (or some gstein-approved name) which
>
> 1) has the OS-specific details specified in enum parameters like in
> the apr_lock_create() patch I posted
>
> 2) is for Real Men/Women(tm) who won't cry if a call to it won't
> compile on Win32 or if we get smarter later and tweak the parameter
> list
>
> (I imagine that apr_lock_create() will call apr_lock_create_np() and
> tell it to use the default mechanism.)
>
> Okay, it's just a special name but it is clearly not in the set of
> interfaces which folks would expect to work the same everywhere.
Re: [PATCH] allow an APR app to choose underlying lock mechanism
Posted by Justin Erenkrantz <je...@ebuilt.com>.
On Mon, Jun 25, 2001 at 07:30:51PM -0400, Jeff Trawick wrote:
> Here's an idea:
>
> Leave apr_lock_create() alone (though I think some other folks wanna
> muck with it :) ).
>
> Add apr_lock_create_np() (or some gstein-approved name) which
>
> 1) has the OS-specific details specified in enum parameters like in
> the apr_lock_create() patch I posted
>
> 2) is for Real Men/Women(tm) who won't cry if a call to it won't
> compile on Win32 or if we get smarter later and tweak the parameter
> list
>
> (I imagine that apr_lock_create() will call apr_lock_create_np() and
> tell it to use the default mechanism.)
>
> Okay, it's just a special name but it is clearly not in the set of
> interfaces which folks would expect to work the same everywhere.
+1. That works for me. -- justin
Re: [PATCH] allow an APR app to choose underlying lock mechanism
Posted by rb...@covalent.net.
On 25 Jun 2001, Jeff Trawick wrote:
> rbb@covalent.net writes:
>
> > > > Would it make more sense to have something that would be more
> > > > specific to each lock type (mutex, semaphore, read/write locks)?
> > >
> > > You tell me :)
> > >
> > > I find the whole notion of needing to tell APR which mechanism to use
> > > fairly klunky, and OS-specific stuff like this really klunky. Given
> > > that premise, I don't have a big problem with APR_LOCK_DEFAULT being
> > > the only thing valid for various platforms and/or lock flavors.
> >
> > I am beginning to see this is very klunky. Is there a better way to do
> > this? I can't think of one, but this just feels ugly and bad to me. :-)
>
> Here's an idea:
>
> Leave apr_lock_create() alone (though I think some other folks wanna
> muck with it :) ).
>
> Add apr_lock_create_np() (or some gstein-approved name) which
>
> 1) has the OS-specific details specified in enum parameters like in
> the apr_lock_create() patch I posted
>
> 2) is for Real Men/Women(tm) who won't cry if a call to it won't
> compile on Win32 or if we get smarter later and tweak the parameter
> list
>
> (I imagine that apr_lock_create() will call apr_lock_create_np() and
> tell it to use the default mechanism.)
>
> Okay, it's just a special name but it is clearly not in the set of
> interfaces which folks would expect to work the same everywhere.
Much better. +1.
Ryan
_____________________________________________________________________________
Ryan Bloom rbb@apache.org
Covalent Technologies rbb@covalent.net
-----------------------------------------------------------------------------
Re: [PATCH] allow an APR app to choose underlying lock mechanism
Posted by Jeff Trawick <tr...@attglobal.net>.
rbb@covalent.net writes:
> > > Would it make more sense to have something that would be more
> > > specific to each lock type (mutex, semaphore, read/write locks)?
> >
> > You tell me :)
> >
> > I find the whole notion of needing to tell APR which mechanism to use
> > fairly klunky, and OS-specific stuff like this really klunky. Given
> > that premise, I don't have a big problem with APR_LOCK_DEFAULT being
> > the only thing valid for various platforms and/or lock flavors.
>
> I am beginning to see this is very klunky. Is there a better way to do
> this? I can't think of one, but this just feels ugly and bad to me. :-)
Here's an idea:
Leave apr_lock_create() alone (though I think some other folks wanna
muck with it :) ).
Add apr_lock_create_np() (or some gstein-approved name) which
1) has the OS-specific details specified in enum parameters like in
the apr_lock_create() patch I posted
2) is for Real Men/Women(tm) who won't cry if a call to it won't
compile on Win32 or if we get smarter later and tweak the parameter
list
(I imagine that apr_lock_create() will call apr_lock_create_np() and
tell it to use the default mechanism.)
Okay, it's just a special name but it is clearly not in the set of
interfaces which folks would expect to work the same everywhere.
--
Jeff Trawick | trawick@attglobal.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: [PATCH] allow an APR app to choose underlying lock mechanism
Posted by rb...@covalent.net.
> > Would it make more sense to have something that would be more
> > specific to each lock type (mutex, semaphore, read/write locks)?
>
> You tell me :)
>
> I find the whole notion of needing to tell APR which mechanism to use
> fairly klunky, and OS-specific stuff like this really klunky. Given
> that premise, I don't have a big problem with APR_LOCK_DEFAULT being
> the only thing valid for various platforms and/or lock flavors.
I am beginning to see this is very klunky. Is there a better way to do
this? I can't think of one, but this just feels ugly and bad to me. :-)
Ryan
>
> > [ See one note about the patch below...]
> >
> > > Index: test/testlock.c
> > > ===================================================================
> > > RCS file: /home/cvs/apr/test/testlock.c,v
> > > retrieving revision 1.3
> > > diff -u -r1.3 testlock.c
> > > --- test/testlock.c 2001/06/06 22:25:43 1.3
> > > +++ test/testlock.c 2001/06/25 20:27:22
> > > @@ -143,7 +143,7 @@
> > > printf("RW Lock Tests\n");
> > > printf("%-60s", " Initializing the RW lock");
> > > s1 = apr_lock_create(&thread_rw_lock, APR_READWRITE, APR_INTRAPROCESS,
> > > - "lock.file", pool);
> > > + APR_LOCK_CREATE, "lock.file", pool);
> > > if (s1 != APR_SUCCESS) {
> > > printf("Failed!\n");
> > > return s1;
> > > @@ -191,7 +191,7 @@
> > > printf("Exclusive lock test\n");
> > > printf("%-60s", " Initializing the lock");
> > > s1 = apr_lock_create(&thread_lock, APR_MUTEX, APR_INTRAPROCESS,
> > > - "lock.file", pool);
> > > + APR_LOCK_CREATE, "lock.file", pool);
> > >
> > > if (s1 != APR_SUCCESS) {
> > > printf("Failed!\n");
> > > @@ -239,8 +239,8 @@
> > >
> > > printf("Testing multiple locking\n");
> > > printf("%-60s"," Creating the lock we'll use");
> > > - if ((rv = apr_lock_create(&multi, APR_MUTEX, APR_LOCKALL,"multi.lock",
> > > - pool)) != APR_SUCCESS) {
> > > + if ((rv = apr_lock_create(&multi, APR_MUTEX, APR_LOCKALL,APR_LOCK_CREATE,
> > > + "multi.lock", pool)) != APR_SUCCESS) {
> > > printf("Failed!\n");
> > > return rv;
> > > }
> >
> > Shouldn't these be APR_LOCK_DEFAULT, or am I missing something?
>
> You bet!!!!!!!!!!!!!!!!!!! I dunno what I'm doing :) Also, I need to
> see why it worked (at least I think it did).
>
> --
> Jeff Trawick | trawick@attglobal.net | PGP public key at web site:
> http://www.geocities.com/SiliconValley/Park/9289/
> Born in Roswell... married an alien...
>
>
_____________________________________________________________________________
Ryan Bloom rbb@apache.org
Covalent Technologies rbb@covalent.net
-----------------------------------------------------------------------------
Re: [PATCH] allow an APR app to choose underlying lock mechanism
Posted by Jeff Trawick <tr...@attglobal.net>.
Justin Erenkrantz <je...@ebuilt.com> writes:
> On Mon, Jun 25, 2001 at 04:30:45PM -0400, Jeff Trawick wrote:
> > Did anybody want this done differently?
>
> What about Read/write locks? Those would use the same function for
> creation, but none of the values for the methods would be valid
> (except the DEFAULT).
Also note that what is there now is not just lock-flavor-specific but
also OS-specific. I would think that as there are choices for
different lock flavors on Unix or choices for anything on other APR
platforms that we could add other APR_LOCK_foo enums.
> Would it make more sense to have something that would be more
> specific to each lock type (mutex, semaphore, read/write locks)?
You tell me :)
I find the whole notion of needing to tell APR which mechanism to use
fairly klunky, and OS-specific stuff like this really klunky. Given
that premise, I don't have a big problem with APR_LOCK_DEFAULT being
the only thing valid for various platforms and/or lock flavors.
> [ See one note about the patch below...]
>
> > Index: test/testlock.c
> > ===================================================================
> > RCS file: /home/cvs/apr/test/testlock.c,v
> > retrieving revision 1.3
> > diff -u -r1.3 testlock.c
> > --- test/testlock.c 2001/06/06 22:25:43 1.3
> > +++ test/testlock.c 2001/06/25 20:27:22
> > @@ -143,7 +143,7 @@
> > printf("RW Lock Tests\n");
> > printf("%-60s", " Initializing the RW lock");
> > s1 = apr_lock_create(&thread_rw_lock, APR_READWRITE, APR_INTRAPROCESS,
> > - "lock.file", pool);
> > + APR_LOCK_CREATE, "lock.file", pool);
> > if (s1 != APR_SUCCESS) {
> > printf("Failed!\n");
> > return s1;
> > @@ -191,7 +191,7 @@
> > printf("Exclusive lock test\n");
> > printf("%-60s", " Initializing the lock");
> > s1 = apr_lock_create(&thread_lock, APR_MUTEX, APR_INTRAPROCESS,
> > - "lock.file", pool);
> > + APR_LOCK_CREATE, "lock.file", pool);
> >
> > if (s1 != APR_SUCCESS) {
> > printf("Failed!\n");
> > @@ -239,8 +239,8 @@
> >
> > printf("Testing multiple locking\n");
> > printf("%-60s"," Creating the lock we'll use");
> > - if ((rv = apr_lock_create(&multi, APR_MUTEX, APR_LOCKALL,"multi.lock",
> > - pool)) != APR_SUCCESS) {
> > + if ((rv = apr_lock_create(&multi, APR_MUTEX, APR_LOCKALL,APR_LOCK_CREATE,
> > + "multi.lock", pool)) != APR_SUCCESS) {
> > printf("Failed!\n");
> > return rv;
> > }
>
> Shouldn't these be APR_LOCK_DEFAULT, or am I missing something?
You bet!!!!!!!!!!!!!!!!!!! I dunno what I'm doing :) Also, I need to
see why it worked (at least I think it did).
--
Jeff Trawick | trawick@attglobal.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: [PATCH] allow an APR app to choose underlying lock mechanism
Posted by Justin Erenkrantz <je...@ebuilt.com>.
On Mon, Jun 25, 2001 at 04:30:45PM -0400, Jeff Trawick wrote:
> Did anybody want this done differently?
What about Read/write locks? Those would use the same function for
creation, but none of the values for the methods would be valid
(except the DEFAULT).
Would it make more sense to have something that would be more
specific to each lock type (mutex, semaphore, read/write locks)?
[ See one note about the patch below...]
> Index: test/testlock.c
> ===================================================================
> RCS file: /home/cvs/apr/test/testlock.c,v
> retrieving revision 1.3
> diff -u -r1.3 testlock.c
> --- test/testlock.c 2001/06/06 22:25:43 1.3
> +++ test/testlock.c 2001/06/25 20:27:22
> @@ -143,7 +143,7 @@
> printf("RW Lock Tests\n");
> printf("%-60s", " Initializing the RW lock");
> s1 = apr_lock_create(&thread_rw_lock, APR_READWRITE, APR_INTRAPROCESS,
> - "lock.file", pool);
> + APR_LOCK_CREATE, "lock.file", pool);
> if (s1 != APR_SUCCESS) {
> printf("Failed!\n");
> return s1;
> @@ -191,7 +191,7 @@
> printf("Exclusive lock test\n");
> printf("%-60s", " Initializing the lock");
> s1 = apr_lock_create(&thread_lock, APR_MUTEX, APR_INTRAPROCESS,
> - "lock.file", pool);
> + APR_LOCK_CREATE, "lock.file", pool);
>
> if (s1 != APR_SUCCESS) {
> printf("Failed!\n");
> @@ -239,8 +239,8 @@
>
> printf("Testing multiple locking\n");
> printf("%-60s"," Creating the lock we'll use");
> - if ((rv = apr_lock_create(&multi, APR_MUTEX, APR_LOCKALL,"multi.lock",
> - pool)) != APR_SUCCESS) {
> + if ((rv = apr_lock_create(&multi, APR_MUTEX, APR_LOCKALL,APR_LOCK_CREATE,
> + "multi.lock", pool)) != APR_SUCCESS) {
> printf("Failed!\n");
> return rv;
> }
Shouldn't these be APR_LOCK_DEFAULT, or am I missing something?
-- justin