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-24 13:11:11 PST Path: archiver1.google.com!news1.google.com!sn-xit-02!sn-xit-06!sn-post-01!supernews.com!corp.supernews.com!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: terminate applications Date: Thu, 24 Jul 2003 15:12:51 -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:40774 Date: 2003-07-24T15:12:51-05:00 List-Id: "Hyman Rosen" wrote in message news:YUGTa.22178$0F4.4025@nwrdny02.gnilink.net... > Randy Brukardt wrote: > > Finalization is the key to building maintainable abstractions, and we simply > > cannot allow cases in which that finalization does not happen. > > But that's not really under your control. In Windows or UNIX, there are > ways to immediately kill a program from the outside, regardless of what > the program would prefer. Of course, the "outside force" killing cannot be avoided. But users hopefully know that doing such things is dangerous. Windows pops up a warning whenever you try to kill a process from the GUI, for instance. > And these services are available to a program > that wishes to invoke them, even on itself. So you don't gain anything > by making believe that such a thing does not exist, and you get in the > way of the programmer who has a perfectly good reason for wanting to do > it. Ah, but we're talking about what goes into the language standard, not what a programmer might do in some circumstance. Moreover, I do not believe that there are many (if any at all) "perfectly good reasons" for unsafely killing yourself. (The standard cannot talk about killing other partitions; everything about running partitions is implementation-defined.) You need to do it if the program is hung, of course, but in that case it is clear that an outside force has to do it. If the program is not hung, there is little value to not doing it safely. Presuming Finalize routines are written to be fault-tolerant (which they have to be for reasons having nothing to do with program exiting), there is no problem with exiting the program with the finalization. If the finalization takes a long time, then there is something seriously wrong with the program design, and that should be addresses, not some suicide package. This need, if it really exists at all, is so rare that I see no reason for it to be included in the standard. OTOH, I would not object to a safe Halt routine (which was defined to be the same as aborting the environment task) which would be (A) well-defined; (B) wouldn't leave critical resources in an undefined state; and (C) be more convinient, especially if you are in some other task. (To abort the environment task requires planning ahead, and it would be of value to avoid that). That would be enough in 99% of the cases, and moreover, the presence of such a routine would prod vendors to insure that aborting the environment task actually works. An Unconditional_Exit routine would have to essentially say "Causes the program to end as soon as possible. It is unspecified whether any finalization is done before the program exits and how any tasks are terminated." And then it would have to be followed with a note suggesting that it be used with extreme caution. I don't see the point. Randy.