mån 2006-08-07 klockan 19:38 +0800 skrev Steven: > From what I can tell, the attached patch will break the current > behaviour. storeCheckCachable() needs to remove the ENTRY_CACHABLE flag > so that other parts of the code know that they can free the memory.
There is only two users of storeCheckCachable(). One is the one we are discussing and mucking with, and there is a storeReleaseRequest() call which automatically clears ENTRY_CACHABLE. The patch moved this from storeCheckCachable() to the call in storeSwapout() in an attempt to make the flow in storeSwapout() easier to follow. The other is a call when the swapout file has been closed, and there any storeReleaseRequest() should be redundant as it has already been done elsewhere in the code if there was any problem.. (bad content length etc). That part also already calls storeSwapMaintainMemObject(). But reading storeCheckCachable() again there is one case which my patch didn't handle. Negative cached objects. My patch threw those out.. > Is the attached patch what you meant (free the memory as soon as we clear > the flag in storeCheckCachable()). Yes, it was my original thought. Just wanted to try to clean up the code flow in storeSwapout while messing with this, but continue doing it the ugly way is simpler so lets stick to that. So lets go for your first patch as it's closest to how the code is used today which should result in least surprises.. Hopefully nobody need to go near this function again in 2.x. Regards Henrik
signature.asc
Description: Detta är en digitalt signerad meddelandedel