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 07:47:08 PST Path: archiver1.google.com!news1.google.com!sn-xit-02!sn-xit-06!sn-xit-09!supernews.com!64.152.100.70.MISMATCH!sjc70.webusenet.com!news.webusenet.com!pd2nf1so.cg.shawcable.net!residential.shaw.ca!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: Thu, 24 Jul 2003 10:46:46 -0400 NNTP-Posting-Host: 24.150.168.167 X-Complaints-To: abuse@cogeco.ca X-Trace: read1.cgocable.net 1059058343 24.150.168.167 (Thu, 24 Jul 2003 10:52:23 EDT) NNTP-Posting-Date: Thu, 24 Jul 2003 10:52:23 EDT Organization: Cogeco Cable Xref: archiver1.google.com comp.lang.ada:40763 Date: 2003-07-24T10:46:46-04:00 List-Id: "Randy Brukardt" wrote in message news:vhu27v687nsdc8@corp.supernews.com... > "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. One of the reasons that kill -9 exists under UNIX is because of "finalization" type activities that can hang a process. What I mean is that you can sometimes kill a process, and then watch it hang as it performs C atexit() processing. After a hang of this type, you then only have two choices: 1. Leave it alone (ignore it) 2. Pull out the kill -9 with extreme prejudice However, kill -9 can have nasty effects under UNIX. For example, under SCO UNIX, I have seen tape device drivers get hung this way for a tape backup. This renders that tape device unusable until the next reboot, since there are no external ways to unravel the problem. Likewise, your example of a win32 process leaving the system unstable. I would maintain that the win32 kernel should take care of disconnecting the interrupt handler, but even that may not be enough (a null or invalid interrupt handler may still leave the system unstable) Consequently I think there are two sides to termination: - for some apps, you don't want finalization (kill -9 approach) - for others, it will be always/sometimes necessary It really comes down to the nature of the application and the design choices made. The criticality of the application is of course, another factor in the choice. > 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. Personally, I believe many of the instances of this problem are due to M$ laziness in getting things right. Sure, there will be some cases that are unsolvable (perhaps device driver issues). UNIX kernels are much more meticulous about what they clean up after a process exit, including semaphores if the SEM_UNDO features are exploited, IMHO. > 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.) To solve MDC's problem, and all that is needed is a sufficiently rounded GPLed Halt package, that applies to popular platforms. That leaves the vendors off of the hook, leaves it out of the standards process, and gives the users the empowerment to do as they please. This package need be nothing more than a very small binding. Or perhaps a GNAT.Halt package ;-) > 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 would generally agree with this, but it may turn out that the bug is in the O/S handling of the event- in which case, a bigger hammer might be required. Warren. -- Warren W. Gay VE3WWG http://home.cogeco.ca/~ve3wwg