On Saturday 24 Jun 2006 09:17, Martin Shepherd wrote:
> On Fri, 23 Jun 2006, Chris Cannam wrote:
> > Operator new always returns a valid result, so there's no reason to
> > check the return value.  If it fails, an exception is thrown rather
> > than returning null.
>
> While this is probably the case for Rosegarden code, is it also true
> of the calls that Rosegarden makes to the Qt and KDE libraries, given
> that those libraries are usually compiled with C++ exceptions
> disabled (ie. -fno-exceptions) .

Good question.  My guess would be that supplying -fno-exceptions when 
compiling a library that uses libstdc++ will not make any difference to 
whether or not an exception is thrown by a new operator in libstdc++ 
(i.e. the compiler won't magically switch to a version of the operator 
that doesn't throw).  So I would expect a failed new in the library to 
throw std::bad_alloc which is then uncatchable because the exception is 
not propagated through the library.

That's a guess though.  It would be interesting to know.

> Once the program has allocated sufficient resources to bring up a
> user interface, and is running stably, if the user invokes a dialog,
> and the dialog fails to come up, due to lack of memory, then there is
> no reason why the dialog couldn't release any resources that it did
> manage to allocate, and then return control to its caller, such that
> the program is returned to the stable state that it was in before the
> user invoked the dialog.

The essential (usability) problem here is that the program is not really 
in a "stable" state even before the allocation fails.  If there is no 
more virtual memory, then the program probably became unusable some 
time ago.  (If the machine has a significant amount of swap.)

Even then there are various different scenarios:

1. Rosegarden eats up all available virtual memory because of a bug.

In this case, crashing is among the best things it can do.  Somehow 
contriving to continue as if nothing had happened would be among the 
worst.  I think this is the first scenario that comes to mind for most 
of us, because it bites us more often during development.  That may 
explain why our response has been so negative, but it probably isn't 
what you were thinking of.

2. Rosegarden eats up all available virtual memory "legitimately" 
because the work it's trying to do needs it.

It's easy to imagine a coarse recovery strategy that would at least be 
better than crashing and that could almost always be carried out 
successfully (abandon the current editing operation if there is one; 
close and destroy all GUI windows; save the document; pop up an error 
dialog; exit).  One could probably implement this starting by simply 
catching std::bad_alloc in main, if one was confident that it would be 
propagated correctly.  I'd certainly be happy to see something like 
this in Rosegarden if it actually worked.

I guess in this situation, doing the minimum amount of recovery 
(abandoning the current dialog or operation and continuing) is unlikely 
to be a great strategy, because it's unlikely to return the machine to 
a really usable state.

3. Another application eats up all available virtual memory.  Rosegarden 
is innocent.

This is the situation in which the minimum disturbance would be ideal. 
You really don't want Rosegarden to do anything.  Abandon no more than 
the current dialog or operation, and hope the other application gets 
killed first.

I've made a bit of an assumption that one process or another is "at 
fault", which obviously isn't always the case.  And there are various 
environmental complications.  If another application goes mad and eats 
all the memory, Rosegarden is increasingly unlikely to get swapped in 
at all (making option 3 less likely than 2).  If Rosegarden's GUI 
process runs out of memory, the sequencer process is unlikely to be 
able to continue either (and vice versa).  An other application that is 
consuming the memory may be something Rosegarden relies on, such as the 
KDE file or print services.  The Linux kernel also kills processes when 
memory is exhausted, and it doesn't always kill the right ones.

I would be interested to know whether there are any C++ applications of 
similar size and GUI complexity to Rosegarden (and aimed at home users 
rather than in systems with defined service and uptime requirements) 
that do actually do rigorous recovery from memory allocation problems 
throughout -- and what percentage of those do more than just save state 
and bail out when something fails.


Chris

Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Rosegarden-devel mailing list
Rosegarden-devel@lists.sourceforge.net - use the link below to unsubscribe
https://lists.sourceforge.net/lists/listinfo/rosegarden-devel

Reply via email to