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-26 08:48:15 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!small1.nntp.aus1.giganews.com!border1.nntp.aus1.giganews.com!nntp.giganews.com!feed.cgocable.net!read1.cgocable.net.POSTED!53ab2750!not-for-mail From: "Warren W. Gay VE3WWG" Newsgroups: comp.lang.ada 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> <3F1FC849.8070202@noplace.com> <3F227F16.2010908@noplace.com> Subject: Re: terminate applications X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Message-ID: <%txUa.381$XK4.16781@read1.cgocable.net> Date: Sat, 26 Jul 2003 11:48:00 -0400 NNTP-Posting-Host: 24.150.168.167 X-Complaints-To: abuse@cogeco.ca X-Trace: read1.cgocable.net 1059234811 24.150.168.167 (Sat, 26 Jul 2003 11:53:31 EDT) NNTP-Posting-Date: Sat, 26 Jul 2003 11:53:31 EDT Organization: Cogeco Cable Xref: archiver1.google.com comp.lang.ada:40840 Date: 2003-07-26T11:48:00-04:00 List-Id: "Nick Roberts" wrote in message news:bfu697$j1mk7$1@ID-25716.news.uni-berlin.de... > "Marin David Condic" wrote in message > news:3F227F16.2010908@noplace.com... > > > The critical point being that if you *don't* give the > > programmer the choice, he'll just do an end-run > > around you anyway and resent the fact that he has > > to go outside the language to get what he wants. > > I think it might be valuable to add to the standard library a procedure, > perhaps: > > procedure Ada.Unsafe_Terminate_Program; > > The RM could define the execution of this procedure maybe as follows: > > ---------- > > Dynamic Semantics > > Unsafe_Terminate_Program causes the execution of all the tasks in all the > partitions of the program to immediately cease execution. No finalization > occurs, and execution within abort-deferred regions will be terminated > without any deferral. A call to Unsafe_Terminate_Program never returns. The > time or place at which each task ceases is undefined. This looks good to me. > Implementation Requirements > > Implementations must document all the potential consequences of the > execution of Unsafe_Terminate_Program which are different to those of normal > program termination. I believe that this part may be too onerous, or at a minimum, should be worded differently. I believe that the documentation should be simply has you have described it under "Dynamic Semantics". Ie. that everything stops, and there is no clean up or defined state left behind. Expecting the compiler vendor to document the consequences is a nightmare for them, IMHO. If the idea of permitting this call scares people, then you could make it illegal without the appropriate pragma or compiler option switch. > Implementation Permissions > > An implementation may omit Unsafe_Terminate_Program if it would be > unreasonable (or too dangerous) to provide it. The problem with this language is the word "dangerous". Who is going to define what is dangerous for me? For someone writing code for NASA or for flight controls, it would be. For me, it is not. I move to strike "(or too dangerous)", since from a software purity point of view, it probably is, most of the time. > The mechanisms used by an > implementation to cause the cessation of execution in tasks other than the > calling task (especially those in separate partitions) is undefined, thus > the speed at which this cessation is propagated, and whether it may or may > not succeed in being propagated to all tasks in a program, is undefined. Fine. > An > implementation may perform some or all finalization, if it would be > unreasonable not to. Again, who defines "unreasonable"? For me, I would say that finalization is not desirable in this case (although perhaps this can be "optional" giving the programmer more control). Finalization is often the source of hangs when things get beyond a "defined set of states", particularly if devices are involved. > An implementation may allow some or all executions > within abort-deferred regions to complete before cessation, if it would be > unreasonable to do otherwise. I would say drop the "unreasonable" (it is not well defined) and simply state that what gets completed or not is undefined (it is implementation dependent). > Notes > > It is intended that Unsafe_Program_Termination not only avoids any > finalization I think you are conflicting withyour self here ;-) > or completion of abort-deferred regions in any part of the Ada > program itself, but also that it avoids as much of the normal termination The word "avoids as much of the normal" is not very well defined. > actions associated with the execution environment as reasonably possible The word "reasonable" again.. > (e.g. finalizations within a run-time environment). It is recommended that > Unsafe_Program_Termination is used only as a last resort, when all other > attempts at bringing a program to completion have failed. I wouldn't make a recommendation here, but only state that it is "unsafe". > It is recommended > that Unsafe_Program_Termination is not used in deliverable software unless > its use is considered unavoidable. Again, I think "unsafe" is enough to state the case, and I would avoid recommendations. > It is strongly recommended that whenever > a program which could possibly execute Unsafe_Program_Termination is > deployed in a different execution environment, or a change is made to that > environment, a thorough check is made as to the worst possible consequences > of its execution. As another recommendation, this is one that I don't think needs to be made. "Unsafe" operations should not be used in areas where safety is a concern. Where it is not a concern, then obviously the developer deserves what he gets if he fails to take this obvious piece of advice to mind. If you insist on putting something in this category of documentation, then I would simply word something like "the behavior may VARY on different environment platforms". > I think this suggestion makes it clear that: the semantics of such a > procedure would be difficult to define, and impossible to enforce or test; > it truly could be really dangerous in some environments. You might consider > all the above a bit too much to add to the RM to be worth it. Overall, I think it is good, but I would eliminate the recommendations and simply label it as "unsafe". For extra safety, you could make it illegal to use without the appropriate use of a pragma or compile time option. -- Warren W. Gay VE3WWG http://home.cogeco.ca/~ve3wwg