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=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,f6ee8ca03c176d76 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-08-29 09:22:35 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!fu-berlin.de!uni-berlin.de!213.54.196.16!not-for-mail From: Dmitry A.Kazakov Newsgroups: comp.lang.ada Subject: Re: stupid question: how can I finish a program? Date: Fri, 30 Aug 2002 06:29:24 +0200 Message-ID: References: Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: 213.54.196.16 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit X-Trace: fu-berlin.de 1030638153 54227661 213.54.196.16 (16 [77047]) User-Agent: KNode/0.4 Xref: archiver1.google.com comp.lang.ada:28560 Date: 2002-08-30T06:29:24+02:00 List-Id: Robert A Duff wrote: > Dmitry A.Kazakov writes: > >> Robert A Duff wrote: >> >> > Dmitry A.Kazakov writes: >> > >> >> For example? Abort without any defined clean-up warranties absolutely >> >> nothing. >> >> >> >> Otherwise, some sort of "finalization" should be defined. For >> >> instance: known tasks killed, known memory returned. But (1) any sort >> >> of finalization could still hang up. >> > >> > If you're running under a proper operating system, then all resources >> > visible outside the program will be cleaned up when the program exits. >> > Therefore, there is no need for finalization to clean up such >> > resources. (I'm talking about the Ada finalization here.) >> >> But cleaning up the resources *is* a finalization. > > You can call it "finalization" if you like, but it's not Ada finalization. Even if OS is written in Ada? (:-)) But yes I did not mean an Ada finalization here. >>... When a file is closed, >> some code has to be executed [no matter on which context]. So there is no >> difference in that respect between how Ada and how an OS does it. > > There is a huge difference: Ada finalization takes place inside the > process, and a broken Ada program can cause finalization to not work. You mean a context here. A good built software should have several [more than two - user process and kernel] contexts. But anyway an exception in a nested context may cause finalization of some objects external to the nested context. There is no difference in how such an object is destroyed when you leave a block and how files are closed after killing a process. > Cleanup performed by the OS happens in the OS, and cannot be damaged > by anything the Ada program does, including using unchecked conversion > of pointers to scribble all over the address space. Even a bug in the > Ada compiler cannot damage the OS. Technically it is an implementation detail. One could achieve a similar effect in Ada by a consequent allocation all objects in separated storage pools local to the blocks you want to be "user-contexts". When block "dies" all memory is reclaimed. It can be made hardware-supported. I would prefer to see some language mechanism to enforce that sort of memory allocation, than try to interface an unknown OS. > As before, I'm only talking about a "proper" OS, which uses hardware > memory protection to ensure security of OS data structures. (Of course > if the OS has bugs, all bets are off.) > > The point is that you can count on the OS to (for example) close open > file handles when the process exits. You cannot count on Ada > finalization to do that. It is true, but I am afraid that future OS's will be even less reliable in that respect than current ones. Consider an OO OS with no files, no external memory, but only persistent objects allocated remotely etc. It could be hard to tie processes such objects. >>... It is possible, but IMO very >> difficult. Alternatively, you can say that it warranties nothing. Then >> well, the external *portable* effect = "does nothing". Who might need >> that thing? > > The Ada RM warrants nothing, but that's OK -- look it up in your OS > manual. > > None of this has anything to do with calling "exit" prematurely. All > these horrible things and lack of warranties you mention are true when > an Ada program exits normally (by getting to the end of the program in > the usual way). If you run this simple program: > > procedure Main is > begin > null; > end Main; > > there is no guarantee in the Ada RM that the OS won't leak memory, > or forget to close the stdout file handle, etc. Because the Universe (OS) ceases to exist with the death of an Ada program! It is an absolutely perfect solipsistic point of view as long as you do not refer OS in ARM. (:-)) > Creating a new feature > like "exit()" would not make things any worse. Doing this you would become a materialist with an imminent obligation to explain how the Universe (OS) works. (:-)) > It's not Ada's job to > talk about what the OS ought to do. -- Regards, Dmitry Kazakov www.dmitry-kazakov.de