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-25 20:28:30 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!headwall.stanford.edu!newshub.sdsu.edu!elnk-nf2-pas!newsfeed.earthlink.net!newsfeed.news2me.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> 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: Date: Fri, 25 Jul 2003 23:28:13 -0400 NNTP-Posting-Host: 24.150.168.167 X-Complaints-To: abuse@cogeco.ca X-Trace: read1.cgocable.net 1059190425 24.150.168.167 (Fri, 25 Jul 2003 23:33:45 EDT) NNTP-Posting-Date: Fri, 25 Jul 2003 23:33:45 EDT Organization: Cogeco Cable Xref: archiver1.google.com comp.lang.ada:40823 Date: 2003-07-25T23:28:13-04:00 List-Id: "Randy Brukardt" wrote in message news:vi0favi91fib92@corp.supernews.com... > "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. The warning is almost useless. It only offers the user a chance to cancel the request. It does not educate a user about whether it is safe or not (it cannot know), and unless you already have inside developer knowledge of the application, you won't know either. Any grandmother will not know which answer to choose for example. So if grannies learn to use the task manager, they will just go ahead and do it if that is what they want! Or more likely, they'll shy away from dangerous talk and end up rebooting because the problem will remain unsolved (which, in the end amounts to almost the same thing as far as the tasks are concerned). So the practical matter is "Houston, we have a problem." The application is hung, so now you have lost control of it. The O/S is no help if you say that killing the processes shouldn't be done. But wait, rebooting amounts to the same thing... "so Houston, we are waiting for your answer from engineering? What are we to do, sitting in our tin can?" ;-) > 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. OK, take the _exit() function away from C programmers and listen to the clamor then! You would be an unpopular fellow ;-) -- Warren W. Gay VE3WWG http://home.cogeco.ca/~ve3wwg