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.
Thank you,
Alex.
+1.
Amos
