Bill Stoddard wrote:
>>
>>--ian
>>
>>Oh.. is anyone using the new PQ code.. i'd like to know if it is working
>>better than what was out there before
>>
>>
doh.
that would be it..
>
>
> Jean-Jacques reports that the PQ code has introduced a seg fault. I haven't tested
>this
> patch fully but I suspect it will fix the problem (or at least fix a problem).
>
> Index: mod_mem_cache.c
> ===================================================================
> RCS file: /home/cvs/httpd-2.0/modules/experimental/mod_mem_cache.c,v
> retrieving revision 1.70
> diff -u -r1.70 mod_mem_cache.c
> --- mod_mem_cache.c 10 Jun 2002 21:10:08 -0000 1.70
> +++ mod_mem_cache.c 14 Jun 2002 23:26:35 -0000
> @@ -192,28 +192,52 @@
> }
> /**
> * callback to free an entry
> - * XXX: just call cleanup_cache_object ?
> + * There is way too much magic in this code. Right now, this callback
> + * is only called out of cache_insert() which is called under protection
> + * of the sconf->lock, which means that we do not (and should not)
> + * attempt to obtain the lock recursively.
> + * The cache API needs some serious cleanup work...
> */
> static void memcache_cache_free(void*a)
> {
> cache_object_t *obj = (cache_object_t *)a;
> - cleanup_cache_object(obj);
> +
> + /* Cleanup the cache object. Object should be removed from the cache
> + * now. Increment the refcount before setting cleanup to avoid a race
> + * condition. A similar pattern is used in remove_url()
> + */
> +#ifdef USE_ATOMICS
> + apr_atomic_inc(&obj->refcount);
> +#else
> + obj->refcount++;
> +#endif
> +
> + obj->cleanup = 1;
> +
> +#ifdef USE_ATOMICS
> + apr_atomic_dec(&obj->refcount);
> +#else
> + obj->refcount--;
> +#endif
> + if (!obj->refcount) {
> + cleanup_cache_object(obj);
> + }
> }
> /*
> * functions return a 'negative' score as lower is better in a priority Q
>
>
