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=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,8893269a4640c798 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-07-23 15:15:28 PST Path: archiver1.google.com!news1.google.com!sn-xit-02!sn-xit-04!sn-xit-01!sn-post-01!supernews.com!corp.supernews.com!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: terminate applications Date: Wed, 23 Jul 2003 17:17:07 -0500 Organization: Posted via Supernews, http://www.supernews.com Message-ID: References: <3F17DF3C.4080204@noplace.com> <3F196773.2060809@noplace.com> <3F19F86C.9050808@attbi.com> <3F1A772F.9060708@noplace.com> <3F1AD6FB.8080806@attbi.com> <3F1BD666.6040506@noplace.com> <3F1C4DA6.3070405@attbi.com> <3F1D29E8.60107@noplace.com> <3F1D2FDC.1070402@noplace.com> <3F1DC75A.5050300@noplace.com> <87oezm9lar.fsf@inf.enst.fr> <3F1E7E1E.8090302@noplace.com> X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4807.1700 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 X-Complaints-To: abuse@supernews.com Xref: archiver1.google.com comp.lang.ada:40731 Date: 2003-07-23T17:17:07-05:00 List-Id: "Marin David Condic" wrote in message news:3F1E7E1E.8090302@noplace.com... > What's wrong with the nothion of having a "Standard Ada Library" that > provides all these sorts of utilities? Why shouldn't it be done in a > Standard Ada Way instead of a Standard C Way? Why shouldn't Ada aim at > providing every capability you find in other languages - and then some - > in order to be the One-Stop Shopping source for the developer? I would be extremely opposed to any standard "library" functions which allowed you to end-run finalization. Indeed, I'd be extremely opposed to *anything* standard that allowed you to end-run finalization. Finalization is the key to building maintainable abstractions, and we simply cannot allow cases in which that finalization does not happen. You might say, "well, the program is going away anyway. Why do we care if the heap is consistent?" Of course, we don't care of the heap is consistent. But we do care that resources that the operating system either does not know about, or does not recover for some reason, are returned. One odd example is that calling the Win32 Exit_Process on some Windows systems can leave open files permanently locked until the next reboot. If the file is something important (say the body of Text_IO), it can leave your computer unusable. A more realistic example is interrupt handlers on Windows 95/98. If you install a handler on those systems, you had better remove if before the program exits. Otherwise, the system will crash the next time that interrupt is triggered. In both of these cases, the problem can be cleared up by the big red power switch. But we certainly don't need a subprogram that effectively requires hitting the power switch afterwards. Of course, finalization also can be used for security purposes (logging out of a system) as well as to prevent other problems. The Win32 documentation for Exit_Process suggests that it should not be called, because it could leave the OS in an inconsistent state. I don't think we want to make it easier to do things that ought to be avoided in the first place. As a vendor, I do not want to be forced, by the inclusion of a poorly defined "Halt" function (which would be very confusing to our users, as we already have a safe-ish "Halt" function), to eliminate all finalization from our run-time, and especially, to be forced to eliminate useful functionality from the run-time. The Janus/Ada Halt runs all finalization before exists, similarly to Aborting the environment task. But then there doesn't seem to be much benefit to having it at all. (We needed it in Ada 83 because you couldn't abort the environment task - it had no name.) If your program hangs when you abort the environment task, it has a bug. That bug should be fixed, because it probably can occur on a normal exit as well. (And if it is a bug in your compiler, you should report it and they ought to fix it.) I don't think that we would be willing to take on the liability (for possible security failures) and increased support costs involved with having such a function. Especially since it really is only useful on a program which is already hung -- at which point you need an outside force to do the killing anyway. Randy.