Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!news.albasani.net!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Ian Collins Newsgroups: comp.lang.c++ Subject: Re: bad alloc Date: Fri, 02 Sep 2011 17:45:26 +1200 Lines: 62 Message-ID: <9cb8rmFfcoU1@mid.individual.net> References: <28a1b207-f29e-4d7d-81ca-490aa64bb808@z18g2000yqb.googlegroups.com> <214b61f9-0a26-446d-9bcf-6da7d70326d9@k15g2000yqd.googlegroups.com> <38b94512-ef13-4168-b057-f095ed7c91b7@c19g2000yqe.googlegroups.com> <9dbad43a-f341-44ac-b3cb-14cb8f3eb909@l2g2000vbn.googlegroups.com> <6bfba27a-a5bd-42df-b3b9-d1d393958665@fd21g2000vbb.googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: individual.net o8mi9Zk8hp2FDAu3Qn5XpQbu/l5UFtQodaJqc6ilv2WgFFI1iu Cancel-Lock: sha1:JbIkvMUxw3B3weg0puMmhi2QBHo= User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.2.9) Gecko/20101021 Lightning/1.0b2 Thunderbird/3.1.4 In-Reply-To: Xref: x330-a1.tempe.blueboxinc.net comp.lang.c++:9645 On 09/ 2/11 04:37 PM, Adam Skutt wrote: > On Sep 1, 7:29 pm, Joshua Maurice wrote: >> >>> No, that does not follow at all. You need to consider the goal of the >>> exception handler: succeed no matter what state the application is in >>> vs. the goals of the rest of the program: succeed only if possible. >>> The latter means no memory allocation. > >> Why do you claim that those are their goals? Has a stakeholder ever >> given you such requirements? > > Yes, plenty of people here seem to be convinced handling OOM (by not > crashing) is a requirement for writing "robust" software; that means > being able to perform some sort of action (such as logging) and > continue onward after the OOM condition. However, some people here > also seem to believe that performing I/O doesn't effect program state, > so their requirements are probably not worth fulfilling. > > Still, this plays into my larger point: even if you have a situation > where you can respond to an OOM condition in some meaningful fashion > other than termination, you're still not assured of success. Put more > plainly, handling OOM doesn't ipso facto ensure additional > robustness. You need to be able to handle the OOM condition and have > a reasonable assurance that your response will actually succeed. It > may be an overstatement on my part to say, "Succeed no matter what", > but making the software more "robust" certainly means tending closer > to that extreme than the opposite. I agree. On a descent hosted environment, memory exhaustion is usually down to either a system wide problem, or a programming error. If you require an application to be "robust" then you can use an external entity to manage and if necessary, restart it. This is common practice for system processes. I have done this in the past where an application ran in a resource limited Solaris zone and was monitored from outside of the zone. On a general purpose system, it is difficult and often impossible for an application to determine how much free memory the system will be able to provide. On systems with over commit any guess will be too optimistic and on system with processes then release memory on demand, too pessimistic. In a resource constrained environment, critical processes can perform all their allocations up front before any other processes start. > As a concrete example, writing all this OOM handling code does me no > good if when my process finally hits a OOM condition, my whole > computer is going to die anyway. For many applications, this is > one of two reasons why they'll ever see an OOM condition. I agree. > Of course, the reality is that all of this rarely makes software more > robust, because actual robust systems generally are pretty tolerant of > things like program termination. As I've said before, frequently it's > even preferable to terminate, even when it would be possible to > recover from the error. This makes the value proposition of handling > OOM even less worthwhile. Indeed, robustness goes beyond a single application. -- Ian Collins