[Kst] Re: low memory

[C. Barth Netterfield]

Here is how I have come to think about the situation:

There is some small hope (P~20%?) that in the next 3-5 years QT+KDElibs+Linux 
could get to the point that it will become low-memory safe.  If this happens, 
there will be an enormous amount of work (and a prescribed procedure) to make 
the apps low-memory safe as well.  If kst is low memory safe, but kwm isn't, 
one has gained nothing.  

If so, putting in the *appropriate* checks could eventually prove to be 
useful.  But I do not have a crystal ball to determine what the KDE/QT 
correct way of handling said failed allocs is going to be.  It may be that 
exceptions will be the 'way to go'. or some new QT_oom_catcher, or ....  My 
guess is that putting in these checks on small allocs now is mainly useless 
even long term.

So: I thought the policy we came to was (I may remember incorrectly):
	-allocation protection on big, variable size (user selected) allocations (new 
vectors, etc) where we could easily bring down an otherwise healthy system.
	-ignore the little ones (new widgets, etc) where if we go survive, someone 
else is going down anyway.

I'm probably wrong, and I've probably flip-flopped, but we have to decide 
something.  So let's decide this.  I would prefer it if this argument ended.

cbn

On Monday 26 July 2004 06:36 pm, George Staikos wrote:
> On Monday 26 July 2004 18:19, Andrew Walker wrote:
> > CVS commit by arwalker:
> >
> > With the advent of Linux being able to function as a memory manager and
> > not just an address space manager this kind of memory check is no longer
> > pointless. George, I'd appreciate if you'd leave these kind of checks
> > alone - which I believe is the decision that we arrived with Barth some
> > time ago.
>
>    You are missing the point here.  The big allocations of primitive blocks
> are perfectly fine to check, especially since they use malloc().  QObjects
> are not.  No matter what you do, you cannot, ever, prevent such a crash on
> OOM with Qt based applications.  The best you could possibly do is catch an
> exception and exit() immediately.  Even checking for null is futile since
> it is equally likely that any internal malloc (Qt does very many!) could
> fail instead of the first one.  I discussed this with various people from
> Trolltech recently.  I also saw slides from them about the number of
> mallocs that are done implicitly in various classes.  It's huge.  (Qt4
> fixes this, but there are always still internal mallocs.)
>
>    In this specific case, in most or all of the call sequences, Kst will
> still be guaranteed to crash because of following calls.  See kstfitdialog
> around line 266.  KstSharedPtr<Plugin> pPtr =
> PluginCollection::self()->.....
>
>     That line will most likely crash.  If not, you've got a big collection
> of them following.  Note that QString() construction and various other
> QString operations used here cause multiple mallocs.
>
>    Putting objects on the stack is insufficient - almost all of them put
> something on the heap in their constructor.
>
>    In the end, adding if() around QObject mallocs is:
> - pointless, since it never returns 0  (the C++ Working Paper requires that
> "new" never return a null pointer)
> - ugly and cluttering up the code
> - adding unnecessary branches
> - doomed to fail even if it did return 0
>
> > --- kdeextragear-2/kst/kst/kstfitdialog_i.cpp  #1.25:1.26
> > @@ -736,7 +736,9 @@ void KstFitDialogI::pluginChanged(int id
> >  void KstFitDialogI::showPluginManager() {
> >    PluginManager *pm = new PluginManager(this, "Plugin Manager");
> > +  if (pm) {
> >    pm->exec();
> >    delete pm;
> >    updatePluginList();
> > +  }
> >  }