You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Aaron Bannert <aa...@clove.org> on 2001/11/17 21:39:59 UTC
[PATCH] convert mod_mem_cache's locks to new APR locks
This patch looks right and compiles (without any new warnings), but
after making the changes I realized that I have no idea how to test
this module. Can someone endorse these changes? They simply convert
the old INTRAPROCESS locks to the new apr_thread_mutex_t type in APR.
-aaron
Index: modules/experimental/mod_mem_cache.c
===================================================================
RCS file: /home/cvs/httpd-2.0/modules/experimental/mod_mem_cache.c,v
retrieving revision 1.9
diff -u -r1.9 mod_mem_cache.c
--- modules/experimental/mod_mem_cache.c 2001/09/11 17:41:05 1.9
+++ modules/experimental/mod_mem_cache.c 2001/11/17 20:20:50
@@ -58,8 +58,11 @@
#define CORE_PRIVATE
+#include <apr_thread_mutex.h>
+
#include "mod_cache.h"
#include "ap_mpm.h"
+
#define MAX_CACHE 5000
module AP_MODULE_DECLARE_DATA mem_cache_module;
@@ -94,7 +97,7 @@
} mem_cache_object_t;
typedef struct {
- apr_lock_t *lock;
+ apr_thread_mutex_t *lock;
apr_hash_t *cacheht;
int space;
apr_time_t maxexpire;
@@ -200,7 +203,7 @@
ap_mpm_query(AP_MPMQ_IS_THREADED, &threaded_mpm);
if (threaded_mpm) {
- apr_lock_create(&sconf->lock, APR_MUTEX, APR_INTRAPROCESS, "foo", p);
+ apr_thread_mutex_create(&sconf->lock, APR_THREAD_MUTEX_DEFAULT, p);
}
sconf->cacheht = apr_hash_make(p);
apr_pool_cleanup_register(p, NULL, cleanup_cache_mem, apr_pool_cleanup_null);
@@ -260,14 +263,14 @@
* views of the same content) under a single search key
*/
if (sconf->lock) {
- apr_lock_acquire(sconf->lock);
+ apr_thread_mutex_lock(sconf->lock);
}
tmp_obj = (cache_object_t *) apr_hash_get(sconf->cacheht, key, APR_HASH_KEY_STRING);
if (!tmp_obj) {
apr_hash_set(sconf->cacheht, obj->key, strlen(obj->key), obj);
}
if (sconf->lock) {
- apr_lock_release(sconf->lock);
+ apr_thread_mutex_unlock(sconf->lock);
}
if (tmp_obj) {
@@ -298,11 +301,11 @@
return DECLINED;
}
if (sconf->lock) {
- apr_lock_acquire(sconf->lock);
+ apr_thread_mutex_lock(sconf->lock);
}
obj = (cache_object_t *) apr_hash_get(sconf->cacheht, key, APR_HASH_KEY_STRING);
if (sconf->lock) {
- apr_lock_release(sconf->lock);
+ apr_thread_mutex_unlock(sconf->lock);
}
if (!obj || !(obj->complete)) {
@@ -324,11 +327,11 @@
cache_object_t *obj = h->cache_obj;
if (sconf->lock) {
- apr_lock_acquire(sconf->lock);
+ apr_thread_mutex_lock(sconf->lock);
}
apr_hash_set(sconf->cacheht, obj->key, strlen(obj->key), NULL);
if (sconf->lock) {
- apr_lock_release(sconf->lock);
+ apr_thread_mutex_unlock(sconf->lock);
}
cleanup_cache_object(obj);
@@ -353,11 +356,11 @@
/* First, find the object in the cache */
if (sconf->lock) {
- apr_lock_acquire(sconf->lock);
+ apr_thread_mutex_lock(sconf->lock);
}
obj = (cache_object_t *) apr_hash_get(sconf->cacheht, key, APR_HASH_KEY_STRING);
if (sconf->lock) {
- apr_lock_release(sconf->lock);
+ apr_thread_mutex_unlock(sconf->lock);
}
if (!obj) {
@@ -366,11 +369,11 @@
/* Found it. Now take it out of the cache and free it. */
if (sconf->lock) {
- apr_lock_acquire(sconf->lock);
+ apr_thread_mutex_lock(sconf->lock);
}
apr_hash_set(sconf->cacheht, obj->key, strlen(obj->key), NULL);
if (sconf->lock) {
- apr_lock_release(sconf->lock);
+ apr_thread_mutex_unlock(sconf->lock);
}
cleanup_cache_object(obj);
@@ -523,8 +526,9 @@
{
int val;
- if (sscanf(arg, "%d", &val) != 1)
- return "CacheSize value must be an integer (kBytes)";
+ if (sscanf(arg, "%d", &val) != 1) {
+ return "CacheSize value must be an integer (kBytes)";
+ }
sconf->space = val;
return NULL;
}
Re: [PATCH] convert mod_mem_cache's locks to new APR locks
Posted by Aaron Bannert <aa...@clove.org>.
On Tue, Nov 20, 2001 at 08:14:05AM -0500, Jeff Trawick wrote:
> "Brian Havard" <br...@kheldar.apana.org.au> writes:
>
> > One important difference is that when generating dependencies with EG gcc
> > -MM as our make depend does, only #includes using "" are counted. So <>
> > includes should only refer to fixed system headers.
>
> At this point it seems clear to me that "" has the advantage, at least
> in apps like Apache where there is a lot of overlap between APR
> developers and Apache developers.
I'm sold. How about the guts of the patch? I'm less worried about someting
breaking when it's in "experimental", but I still wanted someone who knows
mod_mem_cache to validate it.
-aaron
Re: [PATCH] convert mod_mem_cache's locks to new APR locks
Posted by Jeff Trawick <tr...@attglobal.net>.
"Brian Havard" <br...@kheldar.apana.org.au> writes:
> One important difference is that when generating dependencies with EG gcc
> -MM as our make depend does, only #includes using "" are counted. So <>
> includes should only refer to fixed system headers.
At this point it seems clear to me that "" has the advantage, at least
in apps like Apache where there is a lot of overlap between APR
developers and Apache developers.
--
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] convert mod_mem_cache's locks to new APR locks
Posted by Brian Havard <br...@kheldar.apana.org.au>.
On 20 Nov 2001 07:13:04 -0500, Jeff Trawick wrote:
>Aaron Bannert <aa...@clove.org> writes:
>
>> On Sat, Nov 17, 2001 at 03:51:10PM -0500, Jeff Trawick wrote:
>> > > +#include <apr_thread_mutex.h>
>> >
>> > just curious... why angle brackets instead of quotes? practically all
>> > includes of apr_foo.h in apache and apr-util use quotes
>>
>> I never really understood why we're using the #include "" syntax for
>> APR includes, when APR is considered an external support library. Paths
>> to those includes have to be specified in the -I/path option anyway,
>> no? Any particular reason to use quotes instead?
>
>I can't think of a reason in 2001. I used to use a compiler that was
>very picky about the distinction between "" and <>. It would only
>look in the compiler installation directories for <> files, but it
>would look in the user-specified search path for "" files. Thus, I
>get nervous when I see non-system-supplied includes in <>. But it has
>been some years since I have encountered such a problem, so that
>doesn't seem like a reason to stick with "".
>
>Consistency, on the other hand, ... :)
One important difference is that when generating dependencies with EG gcc
-MM as our make depend does, only #includes using "" are counted. So <>
includes should only refer to fixed system headers.
EG if test.c contains just:
#include <stdio.h>
#include "stdlib.h"
D:\TMP>gcc -MM test.c
test.o: test.c f:\emx\include\stdlib.h
--
______________________________________________________________________________
| Brian Havard | "He is not the messiah! |
| brianh@kheldar.apana.org.au | He's a very naughty boy!" - Life of Brian |
------------------------------------------------------------------------------
Re: [PATCH] convert mod_mem_cache's locks to new APR locks
Posted by Jeff Trawick <tr...@attglobal.net>.
Aaron Bannert <aa...@clove.org> writes:
> On Sat, Nov 17, 2001 at 03:51:10PM -0500, Jeff Trawick wrote:
> > > +#include <apr_thread_mutex.h>
> >
> > just curious... why angle brackets instead of quotes? practically all
> > includes of apr_foo.h in apache and apr-util use quotes
>
> I never really understood why we're using the #include "" syntax for
> APR includes, when APR is considered an external support library. Paths
> to those includes have to be specified in the -I/path option anyway,
> no? Any particular reason to use quotes instead?
I can't think of a reason in 2001. I used to use a compiler that was
very picky about the distinction between "" and <>. It would only
look in the compiler installation directories for <> files, but it
would look in the user-specified search path for "" files. Thus, I
get nervous when I see non-system-supplied includes in <>. But it has
been some years since I have encountered such a problem, so that
doesn't seem like a reason to stick with "".
Consistency, on the other hand, ... :)
--
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] convert mod_mem_cache's locks to new APR locks
Posted by Aaron Bannert <aa...@clove.org>.
On Sat, Nov 17, 2001 at 03:51:10PM -0500, Jeff Trawick wrote:
> > +#include <apr_thread_mutex.h>
>
> just curious... why angle brackets instead of quotes? practically all
> includes of apr_foo.h in apache and apr-util use quotes
I never really understood why we're using the #include "" syntax for
APR includes, when APR is considered an external support library. Paths
to those includes have to be specified in the -I/path option anyway,
no? Any particular reason to use quotes instead?
-aaron
Re: [PATCH] convert mod_mem_cache's locks to new APR locks
Posted by Jeff Trawick <tr...@attglobal.net>.
Aaron Bannert <aa...@clove.org> writes:
> Index: modules/experimental/mod_mem_cache.c
> ===================================================================
> RCS file: /home/cvs/httpd-2.0/modules/experimental/mod_mem_cache.c,v
> retrieving revision 1.9
> diff -u -r1.9 mod_mem_cache.c
> --- modules/experimental/mod_mem_cache.c 2001/09/11 17:41:05 1.9
> +++ modules/experimental/mod_mem_cache.c 2001/11/17 20:20:50
> @@ -58,8 +58,11 @@
>
> #define CORE_PRIVATE
>
> +#include <apr_thread_mutex.h>
just curious... why angle brackets instead of quotes? practically all
includes of apr_foo.h in apache and apr-util use quotes
--
Jeff Trawick | trawick@attglobal.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...