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