You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cvs@httpd.apache.org by ia...@apache.org on 2001/11/21 18:01:42 UTC
cvs commit: httpd-2.0/modules/cache mod_file_cache.c
ianh 01/11/21 09:01:42
Modified: modules/cache mod_file_cache.c
Log:
let mod_file_cache use the new apr_mmap_dup function
Submitted by: Brian Pane
Revision Changes Path
1.63 +13 -1 httpd-2.0/modules/cache/mod_file_cache.c
Index: mod_file_cache.c
===================================================================
RCS file: /home/cvs/httpd-2.0/modules/cache/mod_file_cache.c,v
retrieving revision 1.62
retrieving revision 1.63
diff -u -r1.62 -r1.63
--- mod_file_cache.c 2001/08/11 04:04:12 1.62
+++ mod_file_cache.c 2001/11/21 17:01:42 1.63
@@ -333,8 +333,20 @@
#if APR_HAS_MMAP
apr_bucket *b;
apr_bucket_brigade *bb = apr_brigade_create(r->pool);
+ apr_mmap_t *mm;
- b = apr_bucket_mmap_create(file->mm, 0, (apr_size_t)file->finfo.size);
+ /* Create a copy of the apr_mmap_t that's marked as
+ * a "non-owner." The reason for this is that the
+ * mmap bucket setaside function might later try to
+ * transfer ownership of the mmap from a request
+ * pool to a parent pool. For this particular mmap,
+ * though, we want the cache to retain ownership so
+ * that it never gets munmapped. Thus we give the
+ * bucket code a non-owner copy to work with.
+ */
+ apr_mmap_dup(&mm, file->mm, r->pool, 0);
+
+ b = apr_bucket_mmap_create(mm, 0, (apr_size_t)file->finfo.size);
APR_BRIGADE_INSERT_TAIL(bb, b);
b = apr_bucket_eos_create();
APR_BRIGADE_INSERT_TAIL(bb, b);
Re: cvs commit: httpd-2.0/modules/cache mod_file_cache.c
Posted by Cliff Woolley <cl...@yahoo.com>.
On Thu, 22 Nov 2001, Brian Pane wrote:
> I agree; doing the dup when we first mmap the file is better because
> it will save us a dup per request.
Can somebody tell me how it is that cleanup_file_cache() _isn't_ closing
the fd's/deleting the mmap's a _second_ time? Or in fact why that
function needs to be there at all? Each fd/mmap already has its own
cleanup registered, so why are we registering another one for them?
--Cliff
--------------------------------------------------------------
Cliff Woolley
cliffwoolley@yahoo.com
Charlottesville, VA
Re: cvs commit: httpd-2.0/modules/cache mod_file_cache.c
Posted by Brian Pane <bp...@pacbell.net>.
Cliff Woolley wrote:
>On 21 Nov 2001 ianh@apache.org wrote:
>
>>ianh 01/11/21 09:01:42
>>
>> Modified: modules/cache mod_file_cache.c
>> Log:
>> let mod_file_cache use the new apr_mmap_dup function
>> Submitted by: Brian Pane
>>
>
>Thanks... I was going to commit the apr_mmap_dup thing myself today, but I
>see you beat me to it. I have a better idea on the mod_file_cache part, I
>think. All we have to do is call apr_mmap_dup when we first set up the
>apr_mmap_t, and cache the dup'ed (non-owner) apr_mmap_t, not the original.
>We don't even need to keep a reference to the original one--we'll never
>use it.
>
I agree; doing the dup when we first mmap the file is better because
it will save us a dup per request.
--Brian
Re: cvs commit: httpd-2.0/modules/cache mod_file_cache.c
Posted by Cliff Woolley <cl...@yahoo.com>.
On 21 Nov 2001 ianh@apache.org wrote:
> ianh 01/11/21 09:01:42
>
> Modified: modules/cache mod_file_cache.c
> Log:
> let mod_file_cache use the new apr_mmap_dup function
> Submitted by: Brian Pane
Thanks... I was going to commit the apr_mmap_dup thing myself today, but I
see you beat me to it. I have a better idea on the mod_file_cache part, I
think. All we have to do is call apr_mmap_dup when we first set up the
apr_mmap_t, and cache the dup'ed (non-owner) apr_mmap_t, not the original.
We don't even need to keep a reference to the original one--we'll never
use it.
Sound reasonable?
--Cliff