How to handle Out-of-Memory in Konqueror?

[Luciano Montanaro]

On Wednesday 25 February 2004 14:30, Josef Weidendorfer wrote:

> Yes. But to get summary information, I have to go down recursively to the 
> deepest level.

Sure. But when finished with a "leaf" directory scan, you could sum the statistics 
and substitute the multiple file nodes with just a "summary" node, thus keeping 
memory consumption within sane limits.

> 
> > By the way, 600 bytes per file are a lot. What kind of data are you
> > collecting?
> 
> It's simple: fsview uses the TreeMap widget which was not supposed to be used 
> in this way, but for call hierarchies in KCachegrind. Currently, a lot of 
> (painting) attributes are stored separately for every rectangle, which is not 
> needed in the case of fsview, and can be avoided.

This may be a useful optimization, but it is not the crucial issue.

> 
> > > First thing: I will have to catch the exception? Or is it enough to check
> > > for zero as return value from new() ?
> >
> > new always returns a valid pointer unless you use nothrow
> > (e.g. QString pippo = new(nothrow) QString(1000); will return 0 if the
> > space can't be allocated.)
> 
> Ah, thanks. I didn't know this. Can this generally be used in KDE code, i.e. 
> are there old compilers we support and which don't allow for this?
> 

It is part of the C++ standard. However, since exceptions are normally disabled,
you can probably assume the nothrow is implicit.

> > However, Linux, at least, will probably manage to allocate the memory, and
> > it will fail when actually trying to access the memory, when it realizes it
> > was too optimistic in resource allocation.
> 
> Unless you use "ulimit" ;-)
> 

Well, even if konqueror does not crash, having it thrashing the disk is not 
good anyway. Fsview is cool, but unless it is made way less memory hungry, 
it can't really be considered for real use. I really hope that can be fixed

Ciao
Luciano