Re: Download hanging

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