On 07/12/2012 09:05 PM, Amos Jeffries wrote: > On 13/07/2012 10:15 a.m., Alex Rousskov wrote: >> On 07/06/2012 10:08 PM, Alex Rousskov wrote: >>> On 07/06/2012 07:11 PM, Amos Jeffries wrote: >>>> On 7/07/2012 2:36 a.m., Alex Rousskov wrote: >>>>> If I get your primary idea correctly, then instead of >>>>> StoreEntry::swapOut() calling e.trimMemory() it will call new >>>>> StoreController::trimMemory(e) and the controller would decide whether >>>>> to proceed with trimming and, if yes, will call e.trimMemory(). >>>>> StoreEntry::trimMemory() will not have any new conditions added then. >>>>> >>>>> If that is what you are suggesting, it sounds good to me, and I can do >>>>> that during commit of v3 patch (it would not change the >>>>> functionality or >>>>> the order of the checks; just move a couple of checks to a different >>>>> class/method). >>>> Yes that was what I meant. And yes it is a design change, the renamed >>>> functions just make it abundantly clearer that portage is either not >>>> possible or needs more than usual careful checking. >>> Since we are not changing the lower-level MemObject methods that do the >>> actual trimming, I will not rename them. I will add a "maybe" prefix to >>> StoreEntry::trimMemory(). I hope this is a reasonable compromise. >> >> Attached is the third take on this fix. Seems to work OK in my tests. I >> think it meets the requirements discussed so far and can be committed >> now, but please let me know if you would like to see more changes. >> >> Patch preamble has the technical details.
> +1. Committed to trunk as r12205. Please apply to v3.2 as well. Thank you, Alex.
