[EMAIL PROTECTED] wrote:
> +return -1*mobj->priority;
Weirdo - why not just -mobj->priority?
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html http://www.thebunker.net/
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert
[EMAIL PROTECTED] wrote:
>stoddard2002/07/05 19:49:59
>
> Modified:modules/arch/win32 mod_win32.c
> modules/experimental mod_mem_cache.c
> Log:
> Fix some Win32 compile breaks caused by Brian Pane's making apr_table_t
> a full incomplete type.
>
Sorry about that. Thank
On Thursday, July 18, 2002, at 12:49 PM, [EMAIL PROTECTED] wrote:
>}
> -if (sconf->max_cache_object_size >= sconf->max_cache_size) {
> +if (sconf->max_cache_object_size >= sconf->max_cache_size*1000) {
>ap_log_error(APLOG_MARK, APLOG_CRIT, 0, s,
>
>
> On Thursday, July 18, 2002, at 12:49 PM, [EMAIL PROTECTED] wrote:
> >}
> > -if (sconf->max_cache_object_size >= sconf->max_cache_size) {
> > +if (sconf->max_cache_object_size >= sconf->max_cache_size*1000) {
> >ap_log_error(APLOG_MARK, APLOG_CRIT, 0, s,
> >
Should the cleanup field be removed from the object structure in
mod_cache.h?>>> [EMAIL PROTECTED] 09/17/04 9:03 AM >>>
stoddard 2004/09/17 08:03:08 Modified: modules/experimental Tag: APACHE_2_0_BRANCH mod_mem_cache.c Log: eliminate cleanup bit in favor of managing the object exclusivel
Jean-Jacques Clar wrote:
Should the cleanup field be removed from the object structure in
mod_cache.h?
Probably so if it's not used by mod_disk_cache.
Bill
Hi Jean-Jacques,
What specific problem is this patch correcting? I committed a fix for 21287 prior to the holidays. The idea
behind using atomic operators on refcount is to avoid the need to acquire the mutex when
incrementing/decrementing refcount.
Bill
[EMAIL PROTECTED] wrote:
clar20
Here is the patch that fill fix the problem reported by 21287
http://cvs.apache.org/viewcvs.cgi/httpd-2.0/modules/experimental/mod_mem_cache.c?r1=1.99&r2=1.100
Bill
Hi Jean-Jacques,
What specific problem is this patch correcting? I committed a fix for
21287 prior to the holidays. The idea behind
Bill,
The patch you committed is only for 21285.
My bet for 21287 (no mutex lock protection in decrement_refcount).
from the bug description:
"There are no mutex lock protection in decrement_refcount if it isdefined USE_ATOMICS.I think you simply forgot the mutex in function decrement_refcou
Jean-Jacques Clar wrote:
Bill,
The patch you committed is only for 21285.
My bet for 21287 (no mutex lock protection in decrement_refcount).
from the bug description:
"/There are no mutex lock protection in decrement_refcount if it is
defined USE_ATOMICS.
I think you simply forgot the mutex in
[EMAIL PROTECTED] writes:
> trawick 01/12/05 07:01:15
>
> Modified:modules/experimental mod_mem_cache.c
> Log:
> if compilation is doomed due to lack of thread support, fail
> the compile with a nicer message
>
> (hopefully this is only temporary?)
Is anybody planning to "f
Doesn't the race condition still exist? For example, I can delete the
object after the if but before the hash_set. You need a mutex, don't
you?
Ryan
> -apr_hash_set(sconf->cacheht, obj->key, strlen(obj->key), NULL);
> +/*
> + * RACE .. some one might have just deleted this
oops.. used the wrong email from address to reply.
there is a mutex around this code.
what I changed was to add the cleanup_cache_object into the mutex lock
Ryan Bloom wrote:
> Doesn't the race condition still exist? For example, I can delete the
> object after the if but before the hash_set.
On 8 Mar 2002 [EMAIL PROTECTED] wrote:
> stoddard02/03/07 20:25:30
>
> Modified:modules/experimental mod_mem_cache.c
> Log:
> Add file handle caching to mod_mem_cache. This is still experimental and
> is enabled by the #define CACHE_FD, which is off by default.
>
> @@ -102,6 +10
Grrr... yep this is a bug and the MS compiler doesn't even flag a warning. Now how to
fix
it... There are no clean options...
Bill
> On 8 Mar 2002 [EMAIL PROTECTED] wrote:
>
> > stoddard02/03/07 20:25:30
> >
> > Modified:modules/experimental mod_mem_cache.c
> > Log:
> > Add file
On 18 Mar 2002 [EMAIL PROTECTED] wrote:
> -#ifdef APR_HAVE_UNISTD_H
> +#if APR_HAVE_UNISTD_H
AGGGHHH sorry about that. Thanks for the fix.
--Cliff
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
On Fri, 2004-01-09 at 03:48, Bill Stoddard wrote:
> > Looks like 21287 it is not a valid defect based on your explanation.
> > How do I rev back my changes?
>
> Here is how you can see the patch:
>
> cvs diff -u -r 1.102 -r 1.103 mod_mem_cache.c
>
> revison numbers are from cvs.apache.org.
>
>
Sander Striker wrote:
On Fri, 2004-01-09 at 03:48, Bill Stoddard wrote:
Looks like 21287 it is not a valid defect based on your explanation.
How do I rev back my changes?
Here is how you can see the patch:
cvs diff -u -r 1.102 -r 1.103 mod_mem_cache.c
revison numbers are from cvs.apache.org.
Ve
18 matches
Mail list logo
