Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: pass (nike.apache.org: domain of minfrin@sharp.fm designates
 72.32.122.20 as permitted sender)
Message-Id: <639EEE61-66A6-4B53-B077-E836F1F125DF@sharp.fm>
From: Graham Leggett <minfrin@sharp.fm>
To: dev@httpd.apache.org
In-Reply-To: <Pine.GSO.4.64.1009171327220.6320@hatchepsut.acc.umu.se>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Subject: Re: mod_disk_cache: making commit_entity() atomic
Date: Fri, 17 Sep 2010 15:13:11 +0200
References: <73045DBA-6220-49BF-8818-09F97C996235@sharp.fm>
 <Pine.GSO.4.64.1009171327220.6320@hatchepsut.acc.umu.se>

On 17 Sep 2010, at 1:41 PM, Niklas Edmundsson wrote:

> I personally favor designs needs at most O_EXCL style write locking.
>
> Having been bitten by various lock-related issues over the years I'm  
> in favor of a explicit-lock-free design if it can be done cleanly  
> and with good performance.
>
> If going this route, I'd suggest to put the entire path to the data  
> file in the header and not just a uniqifying string (to make it  
> easier to split hashing of header and data in the future).

The problem with this is that if you bake the location of the file  
into the cache, you would never be able to move the cache around.

Is there a benefit to keeping headers and bodies separate?

Regards,
Graham
--