From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!newsfeed.fsmpi.rwth-aachen.de!newsfeed.straub-nv.de!reality.xs3.de!news.jacob-sparre.dk!loke.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Dynamic allocation in the predefined language environment Date: Wed, 8 Jul 2015 14:47:22 -0500 Organization: Jacob Sparre Andersen Research & Innovation Message-ID: References: <559a623d$0$293$14726298@news.sunsite.dk><873811cre5.fsf@theworld.com><559a8d12$0$297$14726298@news.sunsite.dk> <559a936c$0$292$14726298@news.sunsite.dk><87twthbaia.fsf@theworld.com><559b9160$0$297$14726298@news.sunsite.dk> <87fv4zvbsf.fsf@theworld.com> NNTP-Posting-Host: rrsoftware.com X-Trace: loke.gir.dk 1436384843 19176 24.196.82.226 (8 Jul 2015 19:47:23 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Wed, 8 Jul 2015 19:47:23 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Xref: news.eternal-september.org comp.lang.ada:26701 Date: 2015-07-08T14:47:22-05:00 List-Id: "Bob Duff" wrote in message news:87fv4zvbsf.fsf@theworld.com... > Matthias-Christian Ott writes: ... >> If you follow the strong exception safety principle from C++, corrupted >> data structures should not be a problem. > > I don't see how. Storage_Error as defined by the language is like an > asynchronous interrupt. When programming with asynchronous interrupts, > you need a way to disable interrupts in usually-short sections of code. > When programming with Storage_Error, you need a way to "disable" running > out of memory. Ada lacks such a feature (and so does every other > programming language I know). It's hard to imagine how any programming language (or language implementation) could protect against running out of memory. At best, one can try to contain the damage, but the usage/availability of memory is pretty much out of the hands of the implementer (unless they're targeting a bare machine). >>...However, you can only do this >> in code that is under your control. >> >> You can somewhat avoid Storage_Error exception while handling >> Storage_Error exceptions by having "spare" memory that you free directly >> after the exception handler is invoked. > > Yes, but Storage_Error is raised when running out of stack memory as > well as heap/pool memory. Stack memory is the more "interesting" issue, > IMHO. Imagine a "when Storage_Error" handler that simply prints a > message "Memory exhausted while processing line N of the input". > No heap-allocation involved, but in theory it can still raise > Storage_Error. Indeed, it often does -- Put_Line is relatively expensive in terms of stack and/or heap memory. On our old 16-bit compilers, the stack for the environment task and the heap grew together -- that way, we could maximize the use of the address space - no fixed size was needed for either the stack or the heap. The net effect though was that when you ran out of memory it was *all* gone. We had a lot of trouble with the exception handling mechanism itself failing because of a lack of memory, and when we fixed that, only the memory freed by unwinding the stack was available -- depending where the handler was, that might not have been much. We added a one-time hack to the runtime to make that a bit less of a problem -- we added a "leeway" setting that triggered Storage_Error a bit too early (if the distance between the top of the heap and top of the stack (stacks growing downwards on Intel machines) is less than Leeway, then Storage_Error is raised), and the setting was decreased after the first triggering of Storage_Error. Of course, that only works once; it's hardly worthwhile for programs that run a long time (like a web server). So Storage_Error handlers are a crap-shoot. I recall one Ada person (Dave Emery, I think) saying the Storage_Error is like a parachute that opens on impact -- it works, but it's very useful. Our compiler has a handler for Storage_Error: when Storage_Error => J2Error.Fatal_Error (128); which is supposed to report the error and then clean up. But it almost never works because there usually isn't enough memory to do the file operations that are used by the error handler and the clean-up that follows. Luckily, modern hosts rarely run out of memory during a compile (that used to be a common problem on CP/M and MS-DOS). The best Storage_Error handlers do as little as possible to recover (or report), because most likely you are in deep trouble. Depending on the compiler's memory model and how your program is structured, it may be impossible to get out of it. Randy. >>...Otherwise there are many >> application-specific possibilities on how to deal with memory allocation >> errors in a spectrum ranging from simply aborting to degradation of >> service/user experience. > > - Bob