Making KMemoryInfo useful (Re: KDE/kdelibs/kdecore)

[Lubos Lunak]

On Saturday 20 of March 2010, Parker Coates wrote:
> On Sat, Mar 20, 2010 at 15:54, Lubos Lunak wrote:
> > if( I_want_100M_for_cache && memoryInfo.update( KMemoryInfo::AvailableRam
> > ) && memoryInfo.detail( KMemoryInfo::AvailableRam ) >= 100 * 1024 * 1024
> > ) ...
> >
> > if( I_need_300M_to_work )
> >    {
> >    if( memoryInfo.update( KMemoryInfo::AvailableMemory ) &&
> > memoryInfo.detail( KMemoryInfo::AvailableMemory ) >= 300 * 1024 * 1024 )
> >       do_work();
> >    else if( memoryInfo.requestMemory( 300 * 1024 * 1024 ))
> >        do_work();
> >    ...
> >
> > void Foo::releaseMemory( size_t amount )
> >    {
> >    size_t freed = 0;
> >    while( !cachedObjects.isEmpty() && freed < amount )
> >        {
> >        freed += cachedObjects.first()->size();
> >        delete cachedObjects.takeFirst();
> >        }
> >    }

> Possibly naive question: Is it not likely that applications would get
> into pushing matches, constantly requesting that others free up RAM
> for them to use?

 Not any more than they do now. Notice that the requesting is done only when 
the memory will be really needed (i.e. not just caching) and the voluntary 
releasing frees caches. So it should work exactly like now, except that apps 
will be able to use free memory for caches when available, and will give it 
back when it will be needed. It should be ok for Gwenview to hold a huge 
cache of images when nothing else would be using the memory anyway, but it 
shouldn't make a e.g. complex Krita operation fail.

-- 
 Lubos Lunak
 openSUSE Boosters team, KDE developer
 l.lunak at suse.cz , l.lunak at kde.org