* Re: stupid question: how can I finish a program? [not found] <c923f575.0208130627.479e0b3d@posting.google.com> @ 2002-08-13 14:37 ` chris.danx 2002-08-13 23:53 ` Robert C. Leif 2002-08-13 14:38 ` David C. Hoos ` (2 subsequent siblings) 3 siblings, 1 reply; 61+ messages in thread From: chris.danx @ 2002-08-13 14:37 UTC (permalink / raw) drmed wrote: > hi, > Is there a function which quit/exit/end a program? -> whitout using > the signals (like SIGINT ... etc). > Only a one-line function. Think GNAT has a procedure to terminate if that's the compiler in question. hang on... Yep, in gnat.os_lib there is a procedure gnat.os_lib.OS_Exit which quits a program. Other compilers might provide a similar function. -- for personal replies change 'spamoff' to 'chris' ^ permalink raw reply [flat|nested] 61+ messages in thread
* RE: stupid question: how can I finish a program? 2002-08-13 14:37 ` stupid question: how can I finish a program? chris.danx @ 2002-08-13 23:53 ` Robert C. Leif 2002-08-14 2:07 ` Wes Groleau 2002-08-14 13:53 ` Marin D. Condic 0 siblings, 2 replies; 61+ messages in thread From: Robert C. Leif @ 2002-08-13 23:53 UTC (permalink / raw) From: Bob Leif To: Chris Dank et al. Since it is quite common to terminate a commercial program after an exception is raised, it would be quite useful if Ada 200? would include a standard procedure for this. -----Original Message----- From: comp.lang.ada-admin@ada.eu.org [mailto:comp.lang.ada-admin@ada.eu.org] On Behalf Of chris.danx Sent: Tuesday, August 13, 2002 7:38 AM To: comp.lang.ada@ada.eu.org Subject: Re: stupid question: how can I finish a program? drmed wrote: > hi, > Is there a function which quit/exit/end a program? -> whitout using > the signals (like SIGINT ... etc). > Only a one-line function. Think GNAT has a procedure to terminate if that's the compiler in question. hang on... Yep, in gnat.os_lib there is a procedure gnat.os_lib.OS_Exit which quits a program. Other compilers might provide a similar function. -- for personal replies change 'spamoff' to 'chris' ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: stupid question: how can I finish a program? 2002-08-13 23:53 ` Robert C. Leif @ 2002-08-14 2:07 ` Wes Groleau 2002-08-14 5:53 ` Robert C. Leif ` (3 more replies) 2002-08-14 13:53 ` Marin D. Condic 1 sibling, 4 replies; 61+ messages in thread From: Wes Groleau @ 2002-08-14 2:07 UTC (permalink / raw) > Since it is quite common to terminate a commercial program after an > exception is raised, it would be quite useful if Ada 200? would include > a standard procedure for this. This has been in Ada all along. If there is no exception handler, the program terminates. If the only exception handler is at the top level, the program terminates after executing the handler. If there is a lower-level exception handler, you convert to one of the above situations by adding "raise;" to the handler. -- Wes Groleau http://freepages.rootsweb.com/~wgroleau ^ permalink raw reply [flat|nested] 61+ messages in thread
* RE: stupid question: how can I finish a program? 2002-08-14 2:07 ` Wes Groleau @ 2002-08-14 5:53 ` Robert C. Leif 2002-08-14 13:30 ` Wes Groleau 2002-08-14 13:56 ` Marin D. Condic ` (2 subsequent siblings) 3 siblings, 1 reply; 61+ messages in thread From: Robert C. Leif @ 2002-08-14 5:53 UTC (permalink / raw) From: Bob Leif To: Wes Groleau Although, you are technically correct, this termination may occur much later than one desires. A large amount of extraneous output can be produced before termination. I normally store the information produced by an exception in a log file. I would like to minimize the size of this file, in order to quickly find my mistakes. -----Original Message----- From: comp.lang.ada-admin@ada.eu.org [mailto:comp.lang.ada-admin@ada.eu.org] On Behalf Of Wes Groleau Sent: Tuesday, August 13, 2002 7:07 PM To: comp.lang.ada@ada.eu.org Subject: Re: stupid question: how can I finish a program? > Since it is quite common to terminate a commercial program after an > exception is raised, it would be quite useful if Ada 200? would include > a standard procedure for this. This has been in Ada all along. If there is no exception handler, the program terminates. If the only exception handler is at the top level, the program terminates after executing the handler. If there is a lower-level exception handler, you convert to one of the above situations by adding "raise;" to the handler. -- Wes Groleau http://freepages.rootsweb.com/~wgroleau ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: stupid question: how can I finish a program? 2002-08-14 5:53 ` Robert C. Leif @ 2002-08-14 13:30 ` Wes Groleau 0 siblings, 0 replies; 61+ messages in thread From: Wes Groleau @ 2002-08-14 13:30 UTC (permalink / raw) > > If there is no exception handler, the program terminates. > > Although, you are technically correct, this termination may occur much > later than one desires. A large amount of extraneous output can be Point taken. -- Wes Groleau http://freepages.rootsweb.com/~wgroleau ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: stupid question: how can I finish a program? 2002-08-14 2:07 ` Wes Groleau 2002-08-14 5:53 ` Robert C. Leif @ 2002-08-14 13:56 ` Marin D. Condic 2002-08-17 15:58 ` Robert Dewar 2002-08-14 19:18 ` Simon Wright 2002-08-15 1:47 ` Robert Dewar 3 siblings, 1 reply; 61+ messages in thread From: Marin D. Condic @ 2002-08-14 13:56 UTC (permalink / raw) Not really. It works for single threaded programs, but not for multi threaded programs. Try it with tasks. Try having one task determine that the whole program should shut down. There is no "shoot this process in the head right this instant and I really mean it!" instruction in Ada. Not a "standard" one, at least. Not one that will work with all possible Ada programs. MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling Digital. Our Vision is to be the biggest supplier worldwide of digital gateway technology. www.pacemicro.com "Wes Groleau" <wesgroleau@despammed.com> wrote in message news:3D59BB4C.AA21BDA@despammed.com... > > This has been in Ada all along. > > If there is no exception handler, the program terminates. > > If the only exception handler is at the top level, > the program terminates after executing the handler. > > If there is a lower-level exception handler, you convert > to one of the above situations by adding "raise;" > to the handler. > > -- > Wes Groleau > http://freepages.rootsweb.com/~wgroleau ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: stupid question: how can I finish a program? 2002-08-14 13:56 ` Marin D. Condic @ 2002-08-17 15:58 ` Robert Dewar 0 siblings, 0 replies; 61+ messages in thread From: Robert Dewar @ 2002-08-17 15:58 UTC (permalink / raw) "Marin D. Condic" <not.valid@acm.org> wrote in message news:<ajdnjb$k2k$1@nh.pace.co.uk>... > There is no "shoot this process in the head > right this instant and I really mean it!" instruction in > Ada. Not a "standard" one, at least. Not one that will > work with all possible Ada programs. That's misleading. Aborting the environment task will work. However, in the real world, we seldom have Ada programs, instead we have mixtures of Ada and various libraries and foreign languages, and in this case, you can't depend on anything predefined in Ada to work, and the issue of immediate termination becomes somewhat system dependent. ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: stupid question: how can I finish a program? 2002-08-14 2:07 ` Wes Groleau 2002-08-14 5:53 ` Robert C. Leif 2002-08-14 13:56 ` Marin D. Condic @ 2002-08-14 19:18 ` Simon Wright 2002-08-15 14:02 ` Wes Groleau 2002-08-15 1:47 ` Robert Dewar 3 siblings, 1 reply; 61+ messages in thread From: Simon Wright @ 2002-08-14 19:18 UTC (permalink / raw) Wes Groleau <wesgroleau@despammed.com> writes: > If there is no exception handler, the program terminates. > > If the only exception handler is at the top level, > the program terminates after executing the handler. > > If there is a lower-level exception handler, you convert > to one of the above situations by adding "raise;" > to the handler. This is only true if there are no tasks (apart from the environment task) involved. procedure Term is task T; task body T is begin delay 5.0; end T; begin raise Constraint_Error; end Term; returns you to the command prompt after 5 seconds. smaug[4]$ time ./term raised CONSTRAINT_ERROR : term.adb:8 real 0m5.145s user 0m0.000s sys 0m0.000s ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: stupid question: how can I finish a program? 2002-08-14 19:18 ` Simon Wright @ 2002-08-15 14:02 ` Wes Groleau 0 siblings, 0 replies; 61+ messages in thread From: Wes Groleau @ 2002-08-15 14:02 UTC (permalink / raw) > > If there is no exception handler, the program terminates. > > [etc.] > > This is only true if there are no tasks (apart from the environment > task) involved. Oops. (sheepish grin) If I can temporarily forget that Ada has tasking, I must have been away too long! -- Wes Groleau http://freepages.rootsweb.com/~wgroleau ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: stupid question: how can I finish a program? 2002-08-14 2:07 ` Wes Groleau ` (2 preceding siblings ...) 2002-08-14 19:18 ` Simon Wright @ 2002-08-15 1:47 ` Robert Dewar 2002-08-15 5:14 ` Michael Bode 2002-08-15 5:17 ` tmoran 3 siblings, 2 replies; 61+ messages in thread From: Robert Dewar @ 2002-08-15 1:47 UTC (permalink / raw) Wes Groleau <wesgroleau@despammed.com> wrote in message news:<3D59BB4C.AA21BDA@despammed.com>... > > Since it is quite common to terminate a commercial program after an > > exception is raised, it would be quite useful if Ada 200? would include > > a standard procedure for this. Seems redundant, just abort the environment task, that's the simplest suicide model. ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: stupid question: how can I finish a program? 2002-08-15 1:47 ` Robert Dewar @ 2002-08-15 5:14 ` Michael Bode 2002-08-17 14:28 ` Alfred Hilscher 2002-08-15 5:17 ` tmoran 1 sibling, 1 reply; 61+ messages in thread From: Michael Bode @ 2002-08-15 5:14 UTC (permalink / raw) dewar@gnat.com (Robert Dewar) writes: > Seems redundant, just abort the environment task, that's > the simplest suicide model. I had a similar problem, but my programm has a server task which most of the time waits on blocking socket functions (Accept or String'Read from a socket). I tried raising an exception in the main task, killing the server task with abort or the select ... abort construct, but this didn't work. Probably I should't expect this to work. So I just kill the program with Gnat.OS_Lib.OS_Exit. I wonder if there is a way to do this with standard functions. ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: stupid question: how can I finish a program? 2002-08-15 5:14 ` Michael Bode @ 2002-08-17 14:28 ` Alfred Hilscher 0 siblings, 0 replies; 61+ messages in thread From: Alfred Hilscher @ 2002-08-17 14:28 UTC (permalink / raw) To: Michael Bode Michael Bode schrieb: > > dewar@gnat.com (Robert Dewar) writes: > > > Seems redundant, just abort the environment task, that's > > the simplest suicide model. > > I had a similar problem, but my programm has a server task which most > of the time waits on blocking socket functions (Accept or String'Read > from a socket). Hi Michael, I had a similar problem. I solved as follows: I have an extra "shutdown-task" which is only responsible for "unblocking" the sockets by calling "WSACancelBlockingCall" (OK windows only, but I think there should be a similar function even on *x systems). This works fine, all blocking calls are unblocked with the return code WSAEINTR. ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: stupid question: how can I finish a program? 2002-08-15 1:47 ` Robert Dewar 2002-08-15 5:14 ` Michael Bode @ 2002-08-15 5:17 ` tmoran 2002-08-15 18:41 ` Robert Dewar 1 sibling, 1 reply; 61+ messages in thread From: tmoran @ 2002-08-15 5:17 UTC (permalink / raw) > Seems redundant, just abort the environment task, that's > the simplest suicide model. But it doesn't accomplish the "murder the kids, then yourself" multi-task suicide. What are the important differences between the environment task aborting itself vs having it execute: declare Emergency_Exit : exception; begin raise Emergency_Exit; end; ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: stupid question: how can I finish a program? 2002-08-15 5:17 ` tmoran @ 2002-08-15 18:41 ` Robert Dewar 0 siblings, 0 replies; 61+ messages in thread From: Robert Dewar @ 2002-08-15 18:41 UTC (permalink / raw) tmoran@acm.org wrote in message news:<gPG69.5381$Ot1.248134805@newssvr13.news.prodigy.com>... > But it doesn't accomplish the "murder the kids, then > yourself" multi-task suicide. Of course it does (read the RM!) > What are the important differences between the > environment task aborting itself vs having it execute: > declare > Emergency_Exit : exception; > begin > raise Emergency_Exit; > end; Obvious difference: only the environment task can usefully do the latter, whereas anyone can abort the environment task (i.e. any task). ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: stupid question: how can I finish a program? 2002-08-13 23:53 ` Robert C. Leif 2002-08-14 2:07 ` Wes Groleau @ 2002-08-14 13:53 ` Marin D. Condic 2002-08-15 17:39 ` tmoran 2002-08-25 2:22 ` Robert Dewar 1 sibling, 2 replies; 61+ messages in thread From: Marin D. Condic @ 2002-08-14 13:53 UTC (permalink / raw) This is a question that seems to come up fairly regularly: "Is there a standard way of forcing an Ada program to terminate?" Since the current answer is "No", but the question keeps coming up, it would seem like proper fodder for an Ada 0x. It shouldn't be hard to incorporate something into the language as either a standard procedure or even some kind of use of existing keywords. I can't imagine it being difficult to implement since most OS's that support processes have some facility for killing a process and on an embedded machine without an OS, it hardly matters what you do (infinite loop?). There might be issues if you wanted an *orderly* shutdown, but I don't see that being the place to use some flavor of a "terminate all;" statement. (How can the compiler decide what is "orderly" and how can it tell that in the process of being "orderly" the program doesn't run off to Flanders and never return? Better to leave that in the hands of the programmer.) MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling Digital. Our Vision is to be the biggest supplier worldwide of digital gateway technology. www.pacemicro.com "Robert C. Leif" <rleif@rleif.com> wrote in message news:mailman.1029282843.28085.comp.lang.ada@ada.eu.org... > From: Bob Leif > To: Chris Dank et al. > Since it is quite common to terminate a commercial program after an > exception is raised, it would be quite useful if Ada 200? would include > a standard procedure for this. > ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: stupid question: how can I finish a program? 2002-08-14 13:53 ` Marin D. Condic @ 2002-08-15 17:39 ` tmoran 2002-08-16 13:46 ` Marin D. Condic 2002-08-25 2:22 ` Robert Dewar 1 sibling, 1 reply; 61+ messages in thread From: tmoran @ 2002-08-15 17:39 UTC (permalink / raw) > forcing an Ada program to terminate?" The problem is that "terminate" is ambiguous. Do you mean terminate the current task? The task and all its children? All tasks in the program? Do you want Finalization to occur or not occur? All, or just some? If the code module that wants to terminate is in fact a reusable component, should it really terminate the whole program and all its tasks, or just the single component. What should happen when a procedure designed as a whole program is used instead as a single procedure in some larger program. Should the larger program terminate? I'm inclined toward raising an unhandled exception. That gives the overall program the option of an "others" handler to limit the "extent of termination". Of course it also means "others" shouldn't be used casually. One problem with a piece of code that aborts the environment task is that it might be called from some other task, which would then continue, with great confusion for all. Probably most people asking the question just want to terminate the single (environment) task in the simple program, with Finalization occurring, and an unhandled exception does that nicely. ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: stupid question: how can I finish a program? 2002-08-15 17:39 ` tmoran @ 2002-08-16 13:46 ` Marin D. Condic 2002-08-17 14:26 ` Warren W. Gay VE3WWG 2002-08-22 19:16 ` tmoran 0 siblings, 2 replies; 61+ messages in thread From: Marin D. Condic @ 2002-08-16 13:46 UTC (permalink / raw) Its hard to tell if my other posts are making it out there in a timely fashion. I made comments elsewhere in more detail about what I think needs to happen. But in case its not clear or getting out there, I'll take another shot at it. Since you can already raise an exception to terminate a given thread and you can do various other forms of task termination and you have a variety of ways of dealing with finalization, etc. I don't really see any need to re-address these things in any new language feature. The one thing you can't do is shoot any arbitrary Ada program square in the head from anywhere in the code and shut it down totally no matter what state it is in. In operating system parlance, we need a way of killing the process that is running the program. Do not pass go. Do not collect $200. :-) (The need to do this may not be an every day occurence, but it happens enough that its worth having a way of addressing it.) Shutting down the environment task comes close, except that it won't terminate *all* Ada programs. Tasks can get into states wherein they cannot be aborted and the language rules are such that you're still left needing to hit ctrl-C if you want the program to shut down. So it would be a good idea to incorporate a standard procedure that would need to do nothing more than call whatever OS function is available to cause the encasing process to be killed. (Are there any workstation-ish OS's that *don't* provide a mechanism for killing a process?) If there is no OS then the whole concept of "terminating the process" doesn't make much sense, since there is nothing to return control to. In this case you just insert an infinite loop - the program is effectively stopped. MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling Digital. Our Vision is to be the biggest supplier worldwide of digital gateway technology. www.pacemicro.com <tmoran@acm.org> wrote in message news:cHR69.6930$VV.242093357@newssvr21.news.prodigy.com... > > The problem is that "terminate" is ambiguous. Do you mean terminate > the current task? The task and all its children? All tasks in the > program? Do you want Finalization to occur or not occur? All, or just > some? If the code module that wants to terminate is in fact a reusable > component, should it really terminate the whole program and all its > tasks, or just the single component. What should happen when a > procedure designed as a whole program is used instead as a single > procedure in some larger program. Should the larger program terminate? > I'm inclined toward raising an unhandled exception. That gives the > overall program the option of an "others" handler to limit the "extent > of termination". Of course it also means "others" shouldn't be used > casually. One problem with a piece of code that aborts the environment > task is that it might be called from some other task, which would then > continue, with great confusion for all. > Probably most people asking the question just want to terminate the > single (environment) task in the simple program, with Finalization > occurring, and an unhandled exception does that nicely. ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: stupid question: how can I finish a program? 2002-08-16 13:46 ` Marin D. Condic @ 2002-08-17 14:26 ` Warren W. Gay VE3WWG 2002-08-22 19:16 ` tmoran 1 sibling, 0 replies; 61+ messages in thread From: Warren W. Gay VE3WWG @ 2002-08-17 14:26 UTC (permalink / raw) Marin D. Condic wrote: ... > Since you can already raise an exception to terminate a given thread and you > can do various other forms of task termination and you have a variety of > ways of dealing with finalization, etc. I don't really see any need to > re-address these things in any new language feature. The one thing you can't > do is shoot any arbitrary Ada program square in the head from anywhere in > the code and shut it down totally no matter what state it is in. Actually this same situation does come up at the operating system level (UNIX anyway) at times. Imagine a process that is writing out a tape, but the tape unit is hung up because of tape I/O errors (or driver bug), or waiting a tape change etc., and you try to kill the process doing the tape write. The process stays there, because control is still stuck within the kernel. So some "smart aleck" comes along and does a kill -9 on it, and this eliminates the process alright -- but now the tape drive is dead until the next kernel reboot (because the driver state is now all messed up). This is an actual past experience I used to have with a SCO UNIX platform, and that "smart aleck" was me ;-) The basic message (besides avoiding kill -9) is that there will always likely be situations where stopping a process, task, or whatever is not always immediately possible, without some "cost" associated with it. In Windows, if you have opened some COM/DCOM objects and referenced their various interfaces etc., by killing off the process/thread prematurely will leave the referenced COM objects referenced. Unlike UNIX where there is a SEM_UNDO for semaphores, there is no such recovery under the M$ regime. Those COM/DCOM objects and interfaces stay referenced until the next reboot -- not a good thing for servers. I guess what I am suggesting is that it is better to build in a shutdown protocol, to keep things sane, than it is to rely on a "nuke-em" type of approach. -- Warren W. Gay VE3WWG http://home.cogeco.ca/~ve3wwg ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: stupid question: how can I finish a program? 2002-08-16 13:46 ` Marin D. Condic 2002-08-17 14:26 ` Warren W. Gay VE3WWG @ 2002-08-22 19:16 ` tmoran 2002-08-22 20:54 ` Marin D. Condic 1 sibling, 1 reply; 61+ messages in thread From: tmoran @ 2002-08-22 19:16 UTC (permalink / raw) >Its hard to tell if my other posts are making it out there in a timely It arrived from my news feed today (8/22), though I see it's date, and the date it apparently arrived in Google Groups, was 8/16. My newsgroup 'service' is from SBC Pacific Bell in that internet backwater known as Silicon Valley. ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: stupid question: how can I finish a program? 2002-08-22 19:16 ` tmoran @ 2002-08-22 20:54 ` Marin D. Condic 0 siblings, 0 replies; 61+ messages in thread From: Marin D. Condic @ 2002-08-22 20:54 UTC (permalink / raw) Thanks for the comeback there, driver! :-) My news server lives somewhere in England while I sit in Florida. So to make it out to Silicone Valley it has to take the scenic route. Even at 186,000 Miles per second (not just a good idea - its the law!) it might take a while - but six days? Periodically, there seems to be either big delays or outright loss of messages going through our server. I'll ask our network people to look at it. Thanks. MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling Digital. Our Vision is to be the biggest supplier worldwide of digital gateway technology. www.pacemicro.com <tmoran@acm.org> wrote in message news:nMa99.5035$Z06.356526251@newssvr13.news.prodigy.com... > >Its hard to tell if my other posts are making it out there in a timely > It arrived from my news feed today (8/22), though I see it's date, > and the date it apparently arrived in Google Groups, was 8/16. My > newsgroup 'service' is from SBC Pacific Bell in that internet backwater > known as Silicon Valley. ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: stupid question: how can I finish a program? 2002-08-14 13:53 ` Marin D. Condic 2002-08-15 17:39 ` tmoran @ 2002-08-25 2:22 ` Robert Dewar 2002-08-26 15:59 ` Marin D. Condic 2002-08-27 21:59 ` Robert A Duff 1 sibling, 2 replies; 61+ messages in thread From: Robert Dewar @ 2002-08-25 2:22 UTC (permalink / raw) "Marin D. Condic" <not.valid@acm.org> wrote in message news:<ajdnck$k12$1@nh.pace.co.uk>... > This is a question that seems to come up fairly regularly: "Is there a > standard way of forcing an Ada program to terminate?" Since the current > answer is "No" No, the current answer is "Yes", you can abort the environment task. ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: stupid question: how can I finish a program? 2002-08-25 2:22 ` Robert Dewar @ 2002-08-26 15:59 ` Marin D. Condic 2002-08-27 21:59 ` Robert A Duff 1 sibling, 0 replies; 61+ messages in thread From: Marin D. Condic @ 2002-08-26 15:59 UTC (permalink / raw) Disregarding some intersections of language rules brought up in this forum in the not too distant past that indicate there are some circumstances under which dependent tasks can't be aborted, I'll accept for the moment that this is true. If that's the case, then I've got an Ada program that aborts the environment task and doesn't terminate the program - something I can do quite easily with a control-C. That kind of implies in my mind that either A) Aborting the environment task is not equivalent to "Kill any Ada program right now regardless of what it may be doing" or B) There is a bug in the compiler. If "A" is the case, then it seems reasonable that perhaps Ada could use a standard method of interfacing to the OS to kill the process or otherwise come up with something that causes a program to terminate in all circumstances. MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling Digital. Our Vision is to be the biggest supplier worldwide of digital gateway technology. www.pacemicro.com "Robert Dewar" <dewar@gnat.com> wrote in message news:5ee5b646.0208241822.34540e8b@posting.google.com... > > No, the current answer is "Yes", you can abort the environment task. ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: stupid question: how can I finish a program? 2002-08-25 2:22 ` Robert Dewar 2002-08-26 15:59 ` Marin D. Condic @ 2002-08-27 21:59 ` Robert A Duff 2002-08-28 20:40 ` Dmitry A.Kazakov 1 sibling, 1 reply; 61+ messages in thread From: Robert A Duff @ 2002-08-27 21:59 UTC (permalink / raw) dewar@gnat.com (Robert Dewar) writes: > "Marin D. Condic" <not.valid@acm.org> wrote in message news:<ajdnck$k12$1@nh.pace.co.uk>... > > This is a question that seems to come up fairly regularly: "Is there a > > standard way of forcing an Ada program to terminate?" Since the current > > answer is "No" > > No, the current answer is "Yes", you can abort the environment task. No, that doesn't do it. I believe the original poster wants to kill the program (really, the "partition", in Ada terms, or the "process", in OS terms), even if some tasks are in an abort-deferred state. Furthermore, the desire is to skip finalization. Aborting the env task doesn't do that. So I think it's true that Ada has no portable way of doing what was desired. Furthermore, I think it's a reasonable desire, in some rare cases. On the other hand, every OS has such a mechanism, and on most of them it's called "exit". That's portable enough, in practise. - Bob ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: stupid question: how can I finish a program? 2002-08-27 21:59 ` Robert A Duff @ 2002-08-28 20:40 ` Dmitry A.Kazakov 2002-08-28 13:59 ` Robert A Duff 2002-08-28 14:33 ` Marin D. Condic 0 siblings, 2 replies; 61+ messages in thread From: Dmitry A.Kazakov @ 2002-08-28 20:40 UTC (permalink / raw) Robert A Duff wrote: > No, that doesn't do it. I believe the original poster wants to kill the > program (really, the "partition", in Ada terms, or the "process", in OS > terms), even if some tasks are in an abort-deferred state. Furthermore, > the desire is to skip finalization. Aborting the env task doesn't do > that. > > So I think it's true that Ada has no portable way of doing what was > desired. Furthermore, I think it's a reasonable desire, in some rare > cases. 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. (2) How to define it in a portable way (= in language terms)? -- Regards, Dmitry Kazakov www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: stupid question: how can I finish a program? 2002-08-28 20:40 ` Dmitry A.Kazakov @ 2002-08-28 13:59 ` Robert A Duff 2002-08-28 16:55 ` Darren New 2002-08-29 22:48 ` Dmitry A.Kazakov 2002-08-28 14:33 ` Marin D. Condic 1 sibling, 2 replies; 61+ messages in thread From: Robert A Duff @ 2002-08-28 13:59 UTC (permalink / raw) Dmitry A.Kazakov <mailbox@dmitry-kazakov.de> 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.) Certainly, "exit" will kill all tasks in the program and recover all memory. There is no need for finalization to clean up resources internal to the program, either -- the program is about to vanish. *Some* kinds of finalization might be broken by "exit". For example, if some Finalize routine flushes a buffer to disk, and you want that buffer flushed. So you can't blithely call "exit" without some global knowledge of how finalization is used in your program. If you're not using an operating system then the story is very different. >... (2) How to define it in a portable way (= in language > terms)? Seems pretty straightforward to me. Just define a feature that halts the program and doesn't run any finalization. In an embedded system, the appropriate implementation might be: <<Self>> goto Self; - Bob ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: stupid question: how can I finish a program? 2002-08-28 13:59 ` Robert A Duff @ 2002-08-28 16:55 ` Darren New 2002-08-28 18:36 ` Larry Kilgallen 2002-08-28 22:22 ` Robert A Duff 2002-08-29 22:48 ` Dmitry A.Kazakov 1 sibling, 2 replies; 61+ messages in thread From: Darren New @ 2002-08-28 16:55 UTC (permalink / raw) Robert A Duff wrote: > If you're running under a proper operating system, then all resources > visible outside the program will be cleaned up when the program exits. This is true only in the most trivial sense. If I have a program that contacts a license manager (for example) and grabs the license, then aborts, I could be in trouble. That's why license managers check for that sort of failure. If I create a lock-file, that lock-file doesn't get cleaned up (under UNIX, for example). Other OSes (like Amiga's OS) specifically don't clean up anything at all, as this lets you do things like allocate memory, load a program into it, and start it up and then exit yourself. You have to clean it up for yourself. Some mainframe OSes leave the clean-up to the shell. It's the shell's responsibility to free the memory and close the files. However, I'd expect that one would count the shell as "part of the OS" in these systems. So no, in general, a "proper" operating system doesn't clean up all visible resources. Not even with exit() calls. :-) -- Darren New San Diego, CA, USA (PST). Cryptokeys on demand. ** http://images.fbrtech.com/dnew/ ** Try our EbolaBurgers... So tender they melt in your mouth. ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: stupid question: how can I finish a program? 2002-08-28 16:55 ` Darren New @ 2002-08-28 18:36 ` Larry Kilgallen 2002-08-28 22:22 ` Robert A Duff 1 sibling, 0 replies; 61+ messages in thread From: Larry Kilgallen @ 2002-08-28 18:36 UTC (permalink / raw) In article <3D6D00B9.60EECCFB@san.rr.com>, Darren New <dnew@san.rr.com> writes: > Robert A Duff wrote: >> If you're running under a proper operating system, then all resources >> visible outside the program will be cleaned up when the program exits. > > This is true only in the most trivial sense. If I have a program that > contacts a license manager (for example) and grabs the license, then aborts, > I could be in trouble. That's why license managers check for that sort of > failure. If I create a lock-file, that lock-file doesn't get cleaned up > (under UNIX, for example). > > Other OSes (like Amiga's OS) specifically don't clean up anything at all, as > this lets you do things like allocate memory, load a program into it, and > start it up and then exit yourself. You have to clean it up for yourself. > > Some mainframe OSes leave the clean-up to the shell. It's the shell's > responsibility to free the memory and close the files. However, I'd expect > that one would count the shell as "part of the OS" in these systems. > > So no, in general, a "proper" operating system doesn't clean up all visible > resources. Not even with exit() calls. :-) The "proper" operating system on my computer does. The license manager uses the Distributed Lock Manager and per-user licenses automatically return to the pool on image rundown. ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: stupid question: how can I finish a program? 2002-08-28 16:55 ` Darren New 2002-08-28 18:36 ` Larry Kilgallen @ 2002-08-28 22:22 ` Robert A Duff 2002-08-28 22:30 ` Darren New 2002-08-29 16:35 ` Dennis Lee Bieber 1 sibling, 2 replies; 61+ messages in thread From: Robert A Duff @ 2002-08-28 22:22 UTC (permalink / raw) Darren New <dnew@san.rr.com> writes: > Robert A Duff wrote: > > If you're running under a proper operating system, then all resources > > visible outside the program will be cleaned up when the program exits. > > This is true only in the most trivial sense. If I have a program that > contacts a license manager (for example) and grabs the license, then aborts, > I could be in trouble. That's why license managers check for that sort of > failure. So if it's checked for, what's the problem? My point is that any process can be killed at any point. The process could execute an illegal instruction (Ada allows calls to machine code, for example, and allows Unchecked_Conversion to pointers). Or (in Unix), you can "kill -9" it. The OS has to recover from those nasties without leaking resources. So surely calling "exit" is no worse. >... If I create a lock-file, that lock-file doesn't get cleaned up > (under UNIX, for example). That's why I said, "So you can't blithely call "exit" without some global knowledge of how finalization is used in your program." A program that acquires lock files ought to be robust. For example, check whether a previous dead version of itself created the lock file. > Other OSes (like Amiga's OS) specifically don't clean up anything at all, as > this lets you do things like allocate memory, load a program into it, and > start it up and then exit yourself. You have to clean it up for yourself. I don't know Amiga, but it seems to me that if a crashed program causes memory leaks, the OS is broken. > Some mainframe OSes leave the clean-up to the shell. It's the shell's > responsibility to free the memory and close the files. However, I'd expect > that one would count the shell as "part of the OS" in these systems. And one thing Unix does right is to make shells *not* part of the OS. > So no, in general, a "proper" operating system doesn't clean up all visible > resources. Not even with exit() calls. :-) I guess it depends on what "proper" OS means. I'm assuming hardware memory protection, and an OS that takes advantage of that to reclaim resources from crashed processes. - Bob ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: stupid question: how can I finish a program? 2002-08-28 22:22 ` Robert A Duff @ 2002-08-28 22:30 ` Darren New 2002-08-28 23:16 ` Robert A Duff 2002-08-29 16:35 ` Dennis Lee Bieber 1 sibling, 1 reply; 61+ messages in thread From: Darren New @ 2002-08-28 22:30 UTC (permalink / raw) Robert A Duff wrote: > > Darren New <dnew@san.rr.com> writes: > > > Robert A Duff wrote: > > > If you're running under a proper operating system, then all resources > > > visible outside the program will be cleaned up when the program exits. > > > > This is true only in the most trivial sense. If I have a program that > > contacts a license manager (for example) and grabs the license, then aborts, > > I could be in trouble. That's why license managers check for that sort of > > failure. > > So if it's checked for, what's the problem? Well, it isn't the OS doing it. > The OS has to recover from those nasties > without leaking resources. It doesn't recover from those nasties without leaking resources. > So surely calling "exit" is no worse. Correct. I'm not arguing that you shouldn't have "exit". I'm merely saying that "the OS cleans up all externally-visible resources" is an oversimplification. > I don't know Amiga, but it seems to me that if a crashed program causes > memory leaks, the OS is broken. No more than "a crashed program might leave half-written temp files around" is "broken". > > So no, in general, a "proper" operating system doesn't clean up all visible > > resources. Not even with exit() calls. :-) > > I guess it depends on what "proper" OS means. I'm assuming hardware > memory protection, and an OS that takes advantage of that to reclaim > resources from crashed processes. I think it more depends on what you mean by "resources". I've worked on OSes where you had "temp files" that went away when you logged out. UNIX doesn't have that. Are junk-files in /tmp a "resource leak" the OS should clean up? -- Darren New San Diego, CA, USA (PST). Cryptokeys on demand. ** http://images.fbrtech.com/dnew/ ** Try our EbolaBurgers... So tender they melt in your mouth. ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: stupid question: how can I finish a program? 2002-08-28 22:30 ` Darren New @ 2002-08-28 23:16 ` Robert A Duff 2002-08-29 16:49 ` Warren W. Gay VE3WWG 0 siblings, 1 reply; 61+ messages in thread From: Robert A Duff @ 2002-08-28 23:16 UTC (permalink / raw) Darren New <dnew@san.rr.com> writes: > Robert A Duff wrote: > > > > Darren New <dnew@san.rr.com> writes: > > > > > Robert A Duff wrote: > > > > If you're running under a proper operating system, then all resources > > > > visible outside the program will be cleaned up when the program exits. > > > > > > This is true only in the most trivial sense. If I have a program that > > > contacts a license manager (for example) and grabs the license, then aborts, > > > I could be in trouble. That's why license managers check for that sort of > > > failure. > > > > So if it's checked for, what's the problem? > > Well, it isn't the OS doing it. OK, I admit, I was oversimplifying. Still, if the OS allocates some physical memory to a process, and the process dies, the OS ought to reclaim that memory. If a license manager allocates a license to a process, and the process dies, the license manager ought to reclaim it. If an airline terminal crashes in the middle of allocating a seat, the seat should not be permanently empty on all further flights. My point is simply that "exit" shouldn't be any worse than a crash. And that we can't rely on Ada finalization for those sorts of cleanup. > > The OS has to recover from those nasties > > without leaking resources. > > It doesn't recover from those nasties without leaking resources. > > > So surely calling "exit" is no worse. > > Correct. I'm not arguing that you shouldn't have "exit". I'm merely saying > that "the OS cleans up all externally-visible resources" is an > oversimplification. Agreed. > > I don't know Amiga, but it seems to me that if a crashed program causes > > memory leaks, the OS is broken. > > No more than "a crashed program might leave half-written temp files around" > is "broken". I suppose, if somebody can clean up that memory without rebooting. > > > So no, in general, a "proper" operating system doesn't clean up all visible > > > resources. Not even with exit() calls. :-) > > > > I guess it depends on what "proper" OS means. I'm assuming hardware > > memory protection, and an OS that takes advantage of that to reclaim > > resources from crashed processes. > > I think it more depends on what you mean by "resources". I've worked on OSes > where you had "temp files" that went away when you logged out. UNIX doesn't > have that. Are junk-files in /tmp a "resource leak" the OS should clean up? I don't know. I suppose Unix is broken in that regard. I must admit that I've had to delete "by hand" some junk in /tmp, which rogue programs left lying around. - Bob ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: stupid question: how can I finish a program? 2002-08-28 23:16 ` Robert A Duff @ 2002-08-29 16:49 ` Warren W. Gay VE3WWG 2002-08-29 18:55 ` Larry Kilgallen 2002-08-30 8:09 ` Ole-Hjalmar Kristensen 0 siblings, 2 replies; 61+ messages in thread From: Warren W. Gay VE3WWG @ 2002-08-29 16:49 UTC (permalink / raw) Robert A Duff wrote: > Darren New <dnew@san.rr.com> writes: >>Robert A Duff wrote: >>>Darren New <dnew@san.rr.com> writes: >>>>Robert A Duff wrote: >>>> >>>>>If you're running under a proper operating system, then all resources >>>>>visible outside the program will be cleaned up when the program exits. >>>> >>>>This is true only in the most trivial sense. If I have a program that >>>>contacts a license manager (for example) and grabs the license, then aborts, >>>>I could be in trouble. That's why license managers check for that sort of >>>>failure. >>> >>>So if it's checked for, what's the problem? >> >>Well, it isn't the OS doing it. > > OK, I admit, I was oversimplifying. > > Still, if the OS allocates some physical memory to a process, and the > process dies, the OS ought to reclaim that memory. If a license manager > allocates a license to a process, and the process dies, the license > manager ought to reclaim it. ... Even in "proper O/S" there are occaisions where cleanup is needed, but not automatically done by the O/S. Here are 3 examples of this, that can happen on [pick your] UNIX: - Allocated _SHARED_ memory - Created message queues (IPC) - Create semaphores The reason these are not automatically cleaned up by the O/S is that sometimes you want them to persist beyond the creating process' lifetime (because they are shared by other processes). However, you may also not want those resources to exist upon the process termination -- this depends upon the application, or process involved. > My point is simply that "exit" shouldn't be any worse than a crash. It can be, just see the above. It can leave unwanted IPC resources hanging around, and even worse, in an indeterminant state (for shared memory region could be left partially updated). Also, if exit is called with threads (tasks) involved, and this is invoked in an uncoordinated way, the "cleanup code" itself can barf all over the place leading to things like high CPU usage loops (hanging process), core file or spewing output etc., because now you are expecting cleanup code to cleanup with "indefined state" data. > And that we can't rely on Ada finalization for those sorts of cleanup. Especially in the context of "safe programming" practices. >>I think it more depends on what you mean by "resources". I've worked on OSes >>where you had "temp files" that went away when you logged out. UNIX doesn't >>have that. Are junk-files in /tmp a "resource leak" the OS should clean up? > > I don't know. I suppose Unix is broken in that regard. I must admit > that I've had to delete "by hand" some junk in /tmp, which rogue > programs left lying around. > > - Bob This depends upon the application designer (not the O/S). The temp file is indeed automatically cleaned up by the O/S if the application writer uses the correct calls or does it correctly himself. If you truly want the file to cleanup itself, open(2) it, unlink(2) it, and the file will automatically be cleaned up when the file is close(2) (voluntarily by the application or by the O/S when the process is terminated, even in the kill -9 or abort case). The point is that the O/S is not broken in this regard ;-) Many people rely on the atexit() processing, which is like finalization -- you cannot always count on it in an abort-like termination of the program (definitely not, when kill -9 is involved). But don't blame the O/S for this. This type of cleanup is voluntary application cleanup -- only that the app usually depends upon library routines to do it. -- Warren W. Gay VE3WWG http://home.cogeco.ca/~ve3wwg ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: stupid question: how can I finish a program? 2002-08-29 16:49 ` Warren W. Gay VE3WWG @ 2002-08-29 18:55 ` Larry Kilgallen 2002-08-29 19:17 ` Warren W. Gay VE3WWG 2002-08-30 8:09 ` Ole-Hjalmar Kristensen 1 sibling, 1 reply; 61+ messages in thread From: Larry Kilgallen @ 2002-08-29 18:55 UTC (permalink / raw) In article <3D6E507E.7010805@cogeco.ca>, "Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> writes: > Even in "proper O/S" there are occaisions where cleanup is needed, > but not automatically done by the O/S. Here are 3 examples of > this, that can happen on [pick your] UNIX: > > - Allocated _SHARED_ memory > - Created message queues (IPC) > - Create semaphores > > The reason these are not automatically cleaned up by the O/S is that > sometimes you want them to persist beyond the creating process' > lifetime (because they are shared by other processes). VMS tends toward making those go away when the last accessing program exists. At least for the first one there is an option to make it really permanent, but I don't think I have ever really wanted that. > This depends upon the application designer (not the O/S). The temp file > is indeed automatically cleaned up by the O/S if the application writer > uses the correct calls or does it correctly himself. On top of all those other requirements, you want correct programming ? ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: stupid question: how can I finish a program? 2002-08-29 18:55 ` Larry Kilgallen @ 2002-08-29 19:17 ` Warren W. Gay VE3WWG 0 siblings, 0 replies; 61+ messages in thread From: Warren W. Gay VE3WWG @ 2002-08-29 19:17 UTC (permalink / raw) Larry Kilgallen wrote: > In article <3D6E507E.7010805@cogeco.ca>, "Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> writes: > > >>Even in "proper O/S" there are occaisions where cleanup is needed, >>but not automatically done by the O/S. Here are 3 examples of >>this, that can happen on [pick your] UNIX: >> >> - Allocated _SHARED_ memory >> - Created message queues (IPC) >> - Create semaphores >> >>The reason these are not automatically cleaned up by the O/S is that >>sometimes you want them to persist beyond the creating process' >>lifetime (because they are shared by other processes). > > VMS tends toward making those go away when the last accessing program > exists. At least for the first one there is an option to make it really > permanent, but I don't think I have ever really wanted that. UNIX does support the idea of a SEM_UNDO operation, where semaphores are "undone" if the process is blown away. However, even that is not necessarily the right thing to do (do you want to unlock a botched shared memory region and hope for the best?) >>This depends upon the application designer (not the O/S). The temp file >>is indeed automatically cleaned up by the O/S if the application writer >>uses the correct calls or does it correctly himself. > > On top of all those other requirements, you want correct programming ? Is there any other kind of Ada programmer? ;-) -- Warren W. Gay VE3WWG http://home.cogeco.ca/~ve3wwg ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: stupid question: how can I finish a program? 2002-08-29 16:49 ` Warren W. Gay VE3WWG 2002-08-29 18:55 ` Larry Kilgallen @ 2002-08-30 8:09 ` Ole-Hjalmar Kristensen 2002-08-31 20:39 ` Warren W. Gay VE3WWG 1 sibling, 1 reply; 61+ messages in thread From: Ole-Hjalmar Kristensen @ 2002-08-30 8:09 UTC (permalink / raw) "Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> writes: > Robert A Duff wrote: > > Darren New <dnew@san.rr.com> writes: > >>Robert A Duff wrote: > >>>Darren New <dnew@san.rr.com> writes: > >>>>Robert A Duff wrote: > >>>> > >>>>>If you're running under a proper operating system, then all resources > >>>>>visible outside the program will be cleaned up when the program exits. > >>>> > >>>>This is true only in the most trivial sense. If I have a program that > >>>>contacts a license manager (for example) and grabs the license, then aborts, > >>>>I could be in trouble. That's why license managers check for that sort of > >>>>failure. > >>> > >>>So if it's checked for, what's the problem? > >> > >>Well, it isn't the OS doing it. > > OK, I admit, I was oversimplifying. > > Still, if the OS allocates some physical memory to a process, and the > > process dies, the OS ought to reclaim that memory. If a license manager > > allocates a license to a process, and the process dies, the license > > manager ought to reclaim it. ... > > Even in "proper O/S" there are occaisions where cleanup is needed, > but not automatically done by the O/S. Here are 3 examples of > this, that can happen on [pick your] UNIX: > > - Allocated _SHARED_ memory > - Created message queues (IPC) > - Create semaphores > > The reason these are not automatically cleaned up by the O/S is that > sometimes you want them to persist beyond the creating process' > lifetime (because they are shared by other processes). > Certainly, it can cause a leak, but the leak does not get bigger when you run the program again, because as you point out, you can aquire the same resource again, and it's pretty trivial to check for the existence of those *named* objects on startup. Contrast this with an OS which leaks memory, does not close file handles, etc. On the next run of the program, you will probably aquire a *new* chunk of memory or another file handle, and so the garbage will build up over time. <snip> ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: stupid question: how can I finish a program? 2002-08-30 8:09 ` Ole-Hjalmar Kristensen @ 2002-08-31 20:39 ` Warren W. Gay VE3WWG 0 siblings, 0 replies; 61+ messages in thread From: Warren W. Gay VE3WWG @ 2002-08-31 20:39 UTC (permalink / raw) Ole-Hjalmar Kristensen wrote: > "Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> writes: >>Robert A Duff wrote: >>>Darren New <dnew@san.rr.com> writes: >>>>Robert A Duff wrote: >>>>>Darren New <dnew@san.rr.com> writes: >>>>>>Robert A Duff wrote: ... >>Even in "proper O/S" there are occaisions where cleanup is needed, >>but not automatically done by the O/S. Here are 3 examples of >>this, that can happen on [pick your] UNIX: >> >> - Allocated _SHARED_ memory >> - Created message queues (IPC) >> - Create semaphores >> >>The reason these are not automatically cleaned up by the O/S is that >>sometimes you want them to persist beyond the creating process' >>lifetime (because they are shared by other processes). > > Certainly, it can cause a leak, but the leak does not get bigger when > you run the program again, because as you point out, you can aquire > the same resource again, and it's pretty trivial to check for the > existence of those *named* objects on startup. This is only true, if the application has arranged to make the resource globally identifiable, or has saved the IPC ID. A group of cooperating processes often only creates the necessary IPC resources and only knows them by IPC ID (for example, the resources are created, and a few subsequent fork(2) calls are made to share the resource known by IPC ID). After an abort, the IPC IDs are no longer known to the application -- and will create a new resource set instead. So this really depends upon the application design. THIS IS NOT A "GIVEN". > Contrast this with an > OS which leaks memory, does not close file handles, etc. On the next > run of the program, you will probably aquire a *new* chunk of memory > or another file handle, and so the garbage will build up over time. The very same can and often does happen with IPC resources. Not every application expects to re-use those resources after a process abort. -- Warren W. Gay VE3WWG http://home.cogeco.ca/~ve3wwg ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: stupid question: how can I finish a program? 2002-08-28 22:22 ` Robert A Duff 2002-08-28 22:30 ` Darren New @ 2002-08-29 16:35 ` Dennis Lee Bieber 1 sibling, 0 replies; 61+ messages in thread From: Dennis Lee Bieber @ 2002-08-29 16:35 UTC (permalink / raw) Robert A Duff fed this fish to the penguins on Wednesday 28 August 2002 03:22 pm: > Darren New <dnew@san.rr.com> writes: > >> Other OSes (like Amiga's OS) specifically don't clean up anything at >> all, as this lets you do things like allocate memory, load a program >> into it, and start it up and then exit yourself. You have to clean it >> up for yourself. > > I don't know Amiga, but it seems to me that if a crashed program > causes memory leaks, the OS is broken. > The described behavior is closer to a VMS spawn (or fork() call). Essentially the initial program has done the memory allocation/image load, after which the new process is totally independent (hence responsible for it's own process termination cleanup). One caveat, the Amiga OS did not natively handle virtual/protected memory -- it used a single global address space (it ran on 68000 processors). There were modules to make use of virtual addressing on later processors, but still no protected memory. OTOH, we are talking a system with a multi-priority round-robin preemptive task scheduler that ran off 880K floppies with a graphical (the "text" interface required the graphical libraries just to render text) interface in 256K RAM -- this, when M$ Windows was around the 3.0 (or earlier) where the window manager handled task swapping on top of a non-multitasked base. -- -- > ============================================================== < > wlfraed@ix.netcom.com | Wulfraed Dennis Lee Bieber KD6MOG < > wulfraed@dm.net | Bestiaria Support Staff < > ============================================================== < > Bestiaria Home Page: http://www.beastie.dm.net/ < > Home Page: http://www.dm.net/~wulfraed/ < ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: stupid question: how can I finish a program? 2002-08-28 13:59 ` Robert A Duff 2002-08-28 16:55 ` Darren New @ 2002-08-29 22:48 ` Dmitry A.Kazakov 2002-08-29 15:18 ` Robert A Duff 1 sibling, 1 reply; 61+ messages in thread From: Dmitry A.Kazakov @ 2002-08-29 22:48 UTC (permalink / raw) Robert A Duff wrote: > Dmitry A.Kazakov <mailbox@dmitry-kazakov.de> 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. 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. The actual difference is that Ada precisely specifies what "task abort" means. > Certainly, "exit" will > kill all tasks in the program and recover all memory. There is no need > for finalization to clean up resources internal to the program, either > -- the program is about to vanish. No OS can warranty that *all* external resources will be freed. The margin is very unsharf. What if the process starts some system service? Is that an external resource? > *Some* kinds of finalization might be broken by "exit". For example, if > some Finalize routine flushes a buffer to disk, and you want that buffer > flushed. So you can't blithely call "exit" without some global > knowledge of how finalization is used in your program. > > If you're not using an operating system then the story is very > different. > >>... (2) How to define it in a portable way (= in language >> terms)? > > Seems pretty straightforward to me. Just define a feature that halts > the program and doesn't run any finalization. That's clear, but what kind of external finalization has to be performed? Because you cannot warranty that *all* external resources will be freed, you should specify which ones will be. 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? > In an embedded system, > the appropriate implementation might be: > > <<Self>> goto Self; -- Regards, Dmitry Kazakov www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: stupid question: how can I finish a program? 2002-08-29 22:48 ` Dmitry A.Kazakov @ 2002-08-29 15:18 ` Robert A Duff 2002-08-30 4:29 ` Dmitry A.Kazakov 0 siblings, 1 reply; 61+ messages in thread From: Robert A Duff @ 2002-08-29 15:18 UTC (permalink / raw) Dmitry A.Kazakov <mailbox@dmitry-kazakov.de> writes: > Robert A Duff wrote: > > > Dmitry A.Kazakov <mailbox@dmitry-kazakov.de> 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. >... 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. 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. 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. >...The > actual difference is that Ada precisely specifies what "task abort" means. > > > Certainly, "exit" will > > kill all tasks in the program and recover all memory. There is no need > > for finalization to clean up resources internal to the program, either > > -- the program is about to vanish. > > No OS can warranty that *all* external resources will be freed. Well, OK, I admit I overstated my case. Nonetheless, if you know what external resources your program uses, and you are running under a proper OS, then you can deal with these issues. > That's clear, but what kind of external finalization has to be performed? > Because you cannot warranty that *all* external resources will be freed, > you should specify which ones will be. It's not the job of the Ada RM to talk about what happens outside the Ada program. >... 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. Creating a new feature like "exit()" would not make things any worse. It's not Ada's job to talk about what the OS ought to do. - Bob ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: stupid question: how can I finish a program? 2002-08-29 15:18 ` Robert A Duff @ 2002-08-30 4:29 ` Dmitry A.Kazakov 2002-08-29 16:53 ` Warren W. Gay VE3WWG 2002-08-29 19:03 ` Robert C. Leif 0 siblings, 2 replies; 61+ messages in thread From: Dmitry A.Kazakov @ 2002-08-30 4:29 UTC (permalink / raw) Robert A Duff wrote: > Dmitry A.Kazakov <mailbox@dmitry-kazakov.de> writes: > >> Robert A Duff wrote: >> >> > Dmitry A.Kazakov <mailbox@dmitry-kazakov.de> 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 ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: stupid question: how can I finish a program? 2002-08-30 4:29 ` Dmitry A.Kazakov @ 2002-08-29 16:53 ` Warren W. Gay VE3WWG 2002-08-29 19:03 ` Robert C. Leif 1 sibling, 0 replies; 61+ messages in thread From: Warren W. Gay VE3WWG @ 2002-08-29 16:53 UTC (permalink / raw) Dmitry A.Kazakov wrote: > Robert A Duff wrote: >>Dmitry A.Kazakov <mailbox@dmitry-kazakov.de> writes: >>>Robert A Duff wrote: >>>>Dmitry A.Kazakov <mailbox@dmitry-kazakov.de> writes: ... > 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. I don't think that this is much different from various files on different NFS mounts from being closed prematurely, or with botched updates. The technical management may vary, but the problem already exists today. -- Warren W. Gay VE3WWG http://home.cogeco.ca/~ve3wwg ^ permalink raw reply [flat|nested] 61+ messages in thread
* RE: stupid question: how can I finish a program? 2002-08-30 4:29 ` Dmitry A.Kazakov 2002-08-29 16:53 ` Warren W. Gay VE3WWG @ 2002-08-29 19:03 ` Robert C. Leif 2002-08-29 19:25 ` Warren W. Gay VE3WWG 2002-08-29 20:42 ` Larry Kilgallen 1 sibling, 2 replies; 61+ messages in thread From: Robert C. Leif @ 2002-08-29 19:03 UTC (permalink / raw) From: Bob Leif To: The readers of Comp.Lang.Ada We have been witness to an extended discourse on this subject. Although, it appears that there may not be an utterly reliable solution to this problem, it is quite evident that even an imperfect solution would be better than none. Since as an Ada user I know that the Ada compiler vendor's technical knowledge is better than my own, I would prefer that the vendor supplies their best effort; and that the call to this ubiquitous routine be standardized. ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: stupid question: how can I finish a program? 2002-08-29 19:03 ` Robert C. Leif @ 2002-08-29 19:25 ` Warren W. Gay VE3WWG 2002-08-29 20:42 ` Larry Kilgallen 1 sibling, 0 replies; 61+ messages in thread From: Warren W. Gay VE3WWG @ 2002-08-29 19:25 UTC (permalink / raw) Robert C. Leif wrote: > From: Bob Leif > To: The readers of Comp.Lang.Ada > We have been witness to an extended discourse on this subject. Although, > it appears that there may not be an utterly reliable solution to this > problem, it is quite evident that even an imperfect solution would be > better than none. Since as an Ada user I know that the Ada compiler > vendor's technical knowledge is better than my own, I would prefer that > the vendor supplies their best effort; and that the call to this > ubiquitous routine be standardized. The vendor would have some issue with this however -- when his phone starts ringing with complaining customers about why this "feature" doesn't always work, and that the vendor "should fix this piece of _____, that he paid x bucks for" blah blah blah. The best you can hope for here IMHO, is that the application writer should know both his application and the platform(s) of deployment. -- Warren W. Gay VE3WWG http://home.cogeco.ca/~ve3wwg ^ permalink raw reply [flat|nested] 61+ messages in thread
* RE: stupid question: how can I finish a program? 2002-08-29 19:03 ` Robert C. Leif 2002-08-29 19:25 ` Warren W. Gay VE3WWG @ 2002-08-29 20:42 ` Larry Kilgallen 2002-08-29 20:22 ` Robert A Duff 1 sibling, 1 reply; 61+ messages in thread From: Larry Kilgallen @ 2002-08-29 20:42 UTC (permalink / raw) In article <mailman.1030647842.10008.comp.lang.ada@ada.eu.org>, "Robert C. Leif" <rleif@rleif.com> writes: > From: Bob Leif > To: The readers of Comp.Lang.Ada Please drop those little headers. Thanks. > We have been witness to an extended discourse on this subject. Although, > it appears that there may not be an utterly reliable solution to this > problem, it is quite evident that even an imperfect solution would be > better than none. That is not evident to me. If I know I have to use a system specific technique, I will take care to study the problem. If Ada provides it, I expect it to be robust without me peeking into the innards. ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: stupid question: how can I finish a program? 2002-08-29 20:42 ` Larry Kilgallen @ 2002-08-29 20:22 ` Robert A Duff 2002-08-30 20:59 ` Simon Wright 0 siblings, 1 reply; 61+ messages in thread From: Robert A Duff @ 2002-08-29 20:22 UTC (permalink / raw) Kilgallen@SpamCop.net (Larry Kilgallen) writes: > In article <mailman.1030647842.10008.comp.lang.ada@ada.eu.org>, "Robert C. Leif" <rleif@rleif.com> writes: > > > From: Bob Leif > > To: The readers of Comp.Lang.Ada > > Please drop those little headers. Thanks. :-) :-) :-) We all have our little quirks. :-) > > We have been witness to an extended discourse on this subject. Although, > > it appears that there may not be an utterly reliable solution to this > > problem, it is quite evident that even an imperfect solution would be > > better than none. > > That is not evident to me. If I know I have to use a system specific > technique, I will take care to study the problem. If Ada provides it, > I expect it to be robust without me peeking into the innards. So you should make sure all your Ada programs loop forever, so you never have to deal with those nasty OS issues of what happens when the program exits. ;-) Ada does have this "feature" that when the program gets done it's done. And then it exits into the never-never land of the OS. One wonders what happens to all the files it wrote upon, and all the shared memory partitions it created. - Bob ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: stupid question: how can I finish a program? 2002-08-29 20:22 ` Robert A Duff @ 2002-08-30 20:59 ` Simon Wright 0 siblings, 0 replies; 61+ messages in thread From: Simon Wright @ 2002-08-30 20:59 UTC (permalink / raw) Robert A Duff <bobduff@shell01.TheWorld.com> writes: > Ada does have this "feature" that when the program gets done it's > done. And then it exits into the never-never land of the OS. One > wonders what happens to all the files it wrote upon, and all the > shared memory partitions it created. Just as if you do the same in C, surely! ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: stupid question: how can I finish a program? 2002-08-28 20:40 ` Dmitry A.Kazakov 2002-08-28 13:59 ` Robert A Duff @ 2002-08-28 14:33 ` Marin D. Condic 2002-08-28 22:15 ` Larry Kilgallen 2002-08-29 22:16 ` Dmitry A.Kazakov 1 sibling, 2 replies; 61+ messages in thread From: Marin D. Condic @ 2002-08-28 14:33 UTC (permalink / raw) Oh, and how could it be defined in a portable way? C does it with a couple of standard functions. Ada can make standard subprograms too, so why not? Probably (since it is an OS dependent thing and might not have meaning outside the context of an OS) there should be some sort of standard package like "Ada.OS_Services" that contained proccedure(s) to connect to whatever the OS provides. (I hear something like this is in the works) There can't be *that* many different ways of killing the process that a reasonable compromise answer couldn't be found. What more would be needed than a "Kill_The_Process (Optional_Integer_Return_Code_For_Unix_Freaks) ;" call? Would it need to be dramatically different between Unix/Windows/Mac? Would anyone care if it couldn't be implemented easily on some obscure OS? Would the formal definition need to be any more complicated than: "Implementation Defined - but we suggest that you make it do what any sane person using the target OS would reasonably expect..."? It doesn't seem like Rocket Science to me - nor does it sound like a horendous burden on the compiler writers. The only real question could be "Is it reasonably useful to have such an operation?" and I think the answer is "Yes". MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling Digital. Our Vision is to be the biggest supplier worldwide of digital gateway technology. www.pacemicro.com "Dmitry A.Kazakov" <mailbox@dmitry-kazakov.de> wrote in message news:aki1tq$1ij38n$1@ID-77047.news.dfncis.de... > could still hang up. (2) How to define it in a portable way (= in language > terms)? > > ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: stupid question: how can I finish a program? 2002-08-28 14:33 ` Marin D. Condic @ 2002-08-28 22:15 ` Larry Kilgallen 2002-08-29 15:30 ` Robert A Duff 2002-08-29 22:16 ` Dmitry A.Kazakov 1 sibling, 1 reply; 61+ messages in thread From: Larry Kilgallen @ 2002-08-28 22:15 UTC (permalink / raw) In article <akin0p$fma$1@nh.pace.co.uk>, "Marin D. Condic" <not.valid@acm.org> writes: > There can't be *that* many different ways of killing the process that a > reasonable compromise answer couldn't be found. What more would be needed > than a "Kill_The_Process (Optional_Integer_Return_Code_For_Unix_Freaks) ;" > call? Would it need to be dramatically different between Unix/Windows/Mac? > Would anyone care if it couldn't be implemented easily on some obscure OS? As I recall, you had some VMS background, so VMS is not "obscure" :-) 1. With what error code should one exit (odd numbers mean success) ? 2. Do you want to run exit handlers in the executable image and the various shareable images it invoked ? 3. Do you want to run exit handling in the batch file that is controlling the program ? But you cannot avoid running the exit handlers associated with a privileged shareable image. It is possible to construct a pathelogical case that will not kill the process since that would damage system integrity. ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: stupid question: how can I finish a program? 2002-08-28 22:15 ` Larry Kilgallen @ 2002-08-29 15:30 ` Robert A Duff 0 siblings, 0 replies; 61+ messages in thread From: Robert A Duff @ 2002-08-29 15:30 UTC (permalink / raw) Kilgallen@SpamCop.net (Larry Kilgallen) writes: > In article <akin0p$fma$1@nh.pace.co.uk>, "Marin D. Condic" <not.valid@acm.org> writes: > > > There can't be *that* many different ways of killing the process that a > > reasonable compromise answer couldn't be found. What more would be needed > > than a "Kill_The_Process (Optional_Integer_Return_Code_For_Unix_Freaks) ;" > > call? Would it need to be dramatically different between Unix/Windows/Mac? > > Would anyone care if it couldn't be implemented easily on some obscure OS? > > As I recall, you had some VMS background, so VMS is not "obscure" :-) > > 1. With what error code should one exit (odd numbers mean success) ? This question is answered (as well as it can be) by the Ada.Command_Line package. Of course, there is no completely portable answer, but that didn't prevent this useful package from being standardized. > 2. Do you want to run exit handlers in the executable image > and the various shareable images it invoked ? > 3. Do you want to run exit handling in the batch file that > is controlling the program ? The obvious answer is "implementation dependent". The Ada RM has no business talking about VMS-specific features. Note that these questions arise even for programs that exit normally. The Ada RM doesn't address them. The Ada implementer must choose a sensible answer (like, "Yes, exit handlers are run."). > But you cannot avoid running the exit handlers associated with a > privileged shareable image. It is possible to construct a pathelogical > case that will not kill the process since that would damage system > integrity. Consider this analogy: You can use Ada.Text_IO to write a file. The Ada RM says nothing about what happens to that file after the program is done. (For example, there's no guarantee that another Ada program can read that file back in. If the "file" is really the screen, then the data will quickly vanish!) But that doesn't mean that Ada can't define I/O packages -- it just means that part of their useful semantics is outside the universe considered by the Ada RM. The same is true for "exit", or any other feature that interfaces to the world outside the Ada program. Do you avoid writing programs that do I/O, because I/O is inherently non-portable? ;-) - Bob ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: stupid question: how can I finish a program? 2002-08-28 14:33 ` Marin D. Condic 2002-08-28 22:15 ` Larry Kilgallen @ 2002-08-29 22:16 ` Dmitry A.Kazakov 2002-08-29 13:17 ` Marin D. Condic 2002-08-29 16:59 ` Warren W. Gay VE3WWG 1 sibling, 2 replies; 61+ messages in thread From: Dmitry A.Kazakov @ 2002-08-29 22:16 UTC (permalink / raw) Marin D. Condic wrote: > Oh, and how could it be defined in a portable way? C does it with a couple > of standard functions. Ada can make standard subprograms too, so why not? > Probably (since it is an OS dependent thing and might not have meaning > outside the context of an OS) there should be some sort of standard > package like "Ada.OS_Services" that contained proccedure(s) to connect to > whatever the OS provides. (I hear something like this is in the works) > > There can't be *that* many different ways of killing the process that a > reasonable compromise answer couldn't be found. What more would be needed > than a "Kill_The_Process (Optional_Integer_Return_Code_For_Unix_Freaks) ;" > call? Would it need to be dramatically different between Unix/Windows/Mac? > Would anyone care if it couldn't be implemented easily on some obscure OS? > Would the formal definition need to be any more complicated than: > "Implementation Defined - but we suggest that you make it do what any sane > person using the target OS would reasonably expect..."? It doesn't seem > like Rocket Science to me - nor does it sound like a horendous burden on > the compiler writers. The only real question could be "Is it reasonably > useful to have such an operation?" and I think the answer is "Yes". Consider Windows. To kill a process, does not mean that all DLLs and all non-standard drivers it used get notified. Which also means that even if you have killed a process the system is not brought to the state it had before the process start. Yes, you can define a procedure Kill_The_Process but you cannot specifiy what this procedure does! Which resources will be freed? Will they available after procedure completion? What about access rights? So the single thing which will be portable is the name of the procedure. (:-)) -- Regards, Dmitry Kazakov www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: stupid question: how can I finish a program? 2002-08-29 22:16 ` Dmitry A.Kazakov @ 2002-08-29 13:17 ` Marin D. Condic 2002-08-29 19:32 ` Robert A Duff 2002-08-31 2:40 ` Dmitry A.Kazakov 2002-08-29 16:59 ` Warren W. Gay VE3WWG 1 sibling, 2 replies; 61+ messages in thread From: Marin D. Condic @ 2002-08-29 13:17 UTC (permalink / raw) Yes, I understand that there are potential issues as to what exactly happens from one OS to another and I understand that there are dangers in its use because its behavior can't necessarily deal with everything cleanly or do what you would want it to do under the circumstances. But note that a) Windows does provide an OS call to abort the process and b) I said the following: > > Would the formal definition need to be any more complicated than: > > "Implementation Defined - but we suggest that you make it do what any sane > > person using the target OS would reasonably expect..."? It doesn't seem (In other words, you could have it make monkeys fly out of your nose, but a sane person would expect it to call the OS provided "abort" procedure and do whatever that does.) Just because there is no absolutely safe or absolutely portable or absolutely consistent way of doing something in Ada, doesn't mean it shouldn't be done. A complaint that a lot of C programmers have about Ada is that it keeps stoping them from doing what they want to do. Sometimes that is a good thing, but sometimes its just plain stubbornness on the part of Ada insisting that because an answer isn't "perfect" that it won't provide one that is "good enough". Providing a portable interface to what ANSI C calls "abort();" (and similar...) doesn't sound like something that should be avoided just because it might be misused or that the results might not be consistent across all platforms. MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling Digital. Our Vision is to be the biggest supplier worldwide of digital gateway technology. www.pacemicro.com "Dmitry A.Kazakov" <mailbox@dmitry-kazakov.de> wrote in message news:akkrtr$1jg0vq$1@ID-77047.news.dfncis.de... > > Consider Windows. To kill a process, does not mean that all DLLs and all > non-standard drivers it used get notified. Which also means that even if > you have killed a process the system is not brought to the state it had > before the process start. Yes, you can define a procedure Kill_The_Process > but you cannot specifiy what this procedure does! Which resources will be > freed? Will they available after procedure completion? What about access > rights? So the single thing which will be portable is the name of the > procedure. (:-)) > ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: stupid question: how can I finish a program? 2002-08-29 13:17 ` Marin D. Condic @ 2002-08-29 19:32 ` Robert A Duff 2002-08-31 2:40 ` Dmitry A.Kazakov 1 sibling, 0 replies; 61+ messages in thread From: Robert A Duff @ 2002-08-29 19:32 UTC (permalink / raw) "Marin D. Condic" <not.valid@acm.org> writes: > Just because there is no absolutely safe or absolutely portable or > absolutely consistent way of doing something in Ada, doesn't mean it > shouldn't be done. A complaint that a lot of C programmers have about Ada is > that it keeps stoping them from doing what they want to do. Sometimes that > is a good thing, but sometimes its just plain stubbornness on the part of > Ada insisting that because an answer isn't "perfect" that it won't provide > one that is "good enough". Providing a portable interface to what ANSI C > calls "abort();" (and similar...) doesn't sound like something that should > be avoided just because it might be misused or that the results might not be > consistent across all platforms. I very much agree with that. This kind of reasoning is how we got things like Ada.Command_Line and Get_Immediate into the language. Sure, they're not 100% portable -- they can't be, because they interface with the outside world. But in this case, I can't get too excited about a "standard" version. Why not pragma-Import "exit" or "abort", and use that? That's portable enough, in practise. I have done this (knowing full well what resources my program is meddling with), and gotten it working just fine, with the identical code working on Solaris, Linux, and Windows. It might not work on some embedded board, but this particular program was not an embedded program. It also uses sockets, for example, which I don't expect to be available in the chip that controls a toaster or an airplane. - Bob ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: stupid question: how can I finish a program? 2002-08-29 13:17 ` Marin D. Condic 2002-08-29 19:32 ` Robert A Duff @ 2002-08-31 2:40 ` Dmitry A.Kazakov 2002-08-31 0:10 ` Toshitaka Kumano 1 sibling, 1 reply; 61+ messages in thread From: Dmitry A.Kazakov @ 2002-08-31 2:40 UTC (permalink / raw) Marin D. Condic wrote: > Yes, I understand that there are potential issues as to what exactly > happens from one OS to another and I understand that there are dangers in > its use because its behavior can't necessarily deal with everything > cleanly or do what you would want it to do under the circumstances. But > note that a) Windows does provide an OS call to abort the process They (MS) wrote the following about it: "The TerminateProcess function is used to unconditionally cause a process to exit. Use it only in extreme circumstances. The state of global data maintained by dynamic-link libraries (DLLs) may be compromised if TerminateProcess is used rather than ExitProcess." -- MSDN library > and b) I said the following: >> > Would the formal definition need to be any more complicated than: >> > "Implementation Defined - but we suggest that you make it do what any >> > sane person using the target OS would reasonably expect..."? It >> > doesn't seem > (In other words, you could have it make monkeys fly out of your nose, but > a sane person would expect it to call the OS provided "abort" procedure > and do whatever that does.) I have only one objection - this cannot be called "portable". There is also a problem, where do you want to stop? Portable sockets? Pipes? Mailboxes? FTP? 2D-graphics? 3D? SQL? ... Not that I am against all that (:-)), but it will be very hard to do. > Just because there is no absolutely safe or absolutely portable or > absolutely consistent way of doing something in Ada, doesn't mean it > shouldn't be done. A complaint that a lot of C programmers have about Ada > is that it keeps stoping them from doing what they want to do. Sometimes > that is a good thing, but sometimes its just plain stubbornness on the > part of Ada insisting that because an answer isn't "perfect" that it won't > provide one that is "good enough". Providing a portable interface to what > ANSI C calls "abort();" (and similar...) doesn't sound like something that > should be avoided just because it might be misused or that the results > might not be consistent across all platforms. Well, if so little is required then Annex B is a perfect place for this: Interfaces.POSIX Interfaces.VMS Interfaces.Win32 ... -- Regards, Dmitry Kazakov www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: stupid question: how can I finish a program? 2002-08-31 2:40 ` Dmitry A.Kazakov @ 2002-08-31 0:10 ` Toshitaka Kumano 2002-09-02 21:02 ` Dmitry A.Kazakov 0 siblings, 1 reply; 61+ messages in thread From: Toshitaka Kumano @ 2002-08-31 0:10 UTC (permalink / raw) "Dmitry A.Kazakov" wrote: > Well, if so little is required then Annex B is a perfect place for this: > (snip) > Interfaces.Win32 That will make annual amendments of the ISO standard ? :-) -- Toshitaka Kumano Kamakura, Japan ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: stupid question: how can I finish a program? 2002-08-31 0:10 ` Toshitaka Kumano @ 2002-09-02 21:02 ` Dmitry A.Kazakov 0 siblings, 0 replies; 61+ messages in thread From: Dmitry A.Kazakov @ 2002-09-02 21:02 UTC (permalink / raw) Toshitaka Kumano wrote: > "Dmitry A.Kazakov" wrote: >> Well, if so little is required then Annex B is a perfect place for this: >> > (snip) >> Interfaces.Win32 > > That will make annual amendments of the ISO standard ? > :-) Win64 comes! (:-)) -- Regards, Dmitry Kazakov www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: stupid question: how can I finish a program? 2002-08-29 22:16 ` Dmitry A.Kazakov 2002-08-29 13:17 ` Marin D. Condic @ 2002-08-29 16:59 ` Warren W. Gay VE3WWG 2002-08-29 18:26 ` Marin D. Condic 1 sibling, 1 reply; 61+ messages in thread From: Warren W. Gay VE3WWG @ 2002-08-29 16:59 UTC (permalink / raw) Dmitry A.Kazakov wrote: > Marin D. Condic wrote: >>Oh, and how could it be defined in a portable way? C does it with a couple >>of standard functions. Ada can make standard subprograms too, so why not? >>Probably (since it is an OS dependent thing and might not have meaning >>outside the context of an OS) there should be some sort of standard >>package like "Ada.OS_Services" that contained proccedure(s) to connect to >>whatever the OS provides. (I hear something like this is in the works) >> >>There can't be *that* many different ways of killing the process that a >>reasonable compromise answer couldn't be found. What more would be needed >>than a "Kill_The_Process (Optional_Integer_Return_Code_For_Unix_Freaks) ;" >>call? Would it need to be dramatically different between Unix/Windows/Mac? >>Would anyone care if it couldn't be implemented easily on some obscure OS? >>Would the formal definition need to be any more complicated than: >>"Implementation Defined - but we suggest that you make it do what any sane >>person using the target OS would reasonably expect..."? It doesn't seem >>like Rocket Science to me - nor does it sound like a horendous burden on >>the compiler writers. The only real question could be "Is it reasonably >>useful to have such an operation?" and I think the answer is "Yes". > > Consider Windows. To kill a process, does not mean that all DLLs and all > non-standard drivers it used get notified. Which also means that even if > you have killed a process the system is not brought to the state it had > before the process start. Yes, you can define a procedure Kill_The_Process > but you cannot specifiy what this procedure does! Which resources will be > freed? Will they available after procedure completion? What about access > rights? So the single thing which will be portable is the name of the > procedure. (:-)) The other question that comes up with COM objects is whether or not the object should be "unreferenced". But if you do allow the unref call, then other code may run that may experience "difficulties". The UNIX equivalent of a kill -9 in windows would leave many COM objects referenced after the processes are gone. Yuk. I smell another reboot coming on ;-) -- Warren W. Gay VE3WWG http://home.cogeco.ca/~ve3wwg ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: stupid question: how can I finish a program? 2002-08-29 16:59 ` Warren W. Gay VE3WWG @ 2002-08-29 18:26 ` Marin D. Condic 0 siblings, 0 replies; 61+ messages in thread From: Marin D. Condic @ 2002-08-29 18:26 UTC (permalink / raw) But thats what Windows *does* when you kill a process. Is that an Ada problem or a Windows problem? What if the Ada program crashed? Would we say that the Ada standard should not permit crashes because the effects on the OS are not portable or may be unreliable? :-) (Boy, we'd really have the C/C++ guys on the ropes! "Its against the ARM for an Ada program to crash, so if it does, blame your compiler vendor..." :-) Sure, maybe Windows is an example of rebootive multitasking, but if someone develops on top of Windows, its their design choice and they have to live with the limitations. If Ada had its own flavor of "abort();" under Windows it would be no more dangerous than C or C++ in that regard. MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling Digital. Our Vision is to be the biggest supplier worldwide of digital gateway technology. www.pacemicro.com "Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> wrote in message news:3D6E52EF.2010406@cogeco.ca... > > The other question that comes up with COM objects is whether or not > the object should be "unreferenced". But if you do allow the unref > call, then other code may run that may experience "difficulties". > The UNIX equivalent of a kill -9 in windows would leave many COM > objects referenced after the processes are gone. Yuk. I smell another > reboot coming on ;-) > ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: stupid question: how can I finish a program? [not found] <c923f575.0208130627.479e0b3d@posting.google.com> 2002-08-13 14:37 ` stupid question: how can I finish a program? chris.danx @ 2002-08-13 14:38 ` David C. Hoos 2002-08-13 20:08 ` Adam Beneschan 2002-08-14 6:41 ` Emil Moholth 2002-08-14 7:37 ` Martin Dowie 3 siblings, 1 reply; 61+ messages in thread From: David C. Hoos @ 2002-08-13 14:38 UTC (permalink / raw) In the main program procedure, "return" will do it. ----- Original Message ----- From: "drmed" <jonas.gasser@dataflow.ch> Newsgroups: comp.lang.ada To: <comp.lang.ada@ada.eu.org> Sent: Tuesday, August 13, 2002 9:27 AM Subject: stupid question: how can I finish a program? > hi, > Is there a function which quit/exit/end a program? -> whitout using > the signals (like SIGINT ... etc). > Only a one-line function. > thanks > > jonas > _______________________________________________ > comp.lang.ada mailing list > comp.lang.ada@ada.eu.org > http://ada.eu.org/mailman/listinfo/comp.lang.ada > ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: stupid question: how can I finish a program? 2002-08-13 14:38 ` David C. Hoos @ 2002-08-13 20:08 ` Adam Beneschan 0 siblings, 0 replies; 61+ messages in thread From: Adam Beneschan @ 2002-08-13 20:08 UTC (permalink / raw) "David C. Hoos" <david.c.hoos.sr@ada95.com> wrote in message news:<mailman.1029249602.10046.comp.lang.ada@ada.eu.org>... > In the main program procedure, "return" will do it. If you're not in the main program, a possibility is to define an exception Fatal_Error_Detected or something like that in a library package; then "raise Fatal_Error_Detected" can be used at points when you want to exit the program. In the main program, add an exception handler: begin ... exception when Fatal_Error_Detected => null; -- OR you can add cleanup code if necessary end Main_Program; Also, if there's any other procedure in the program in which you want to perform cleanup code before exiting, you can add an exception handler to the procedure: exception when Fatal_Error_Detected => <cleanup code> raise; > > hi, > > Is there a function which quit/exit/end a program? -> whitout using > > the signals (like SIGINT ... etc). > > Only a one-line function. > > thanks -- Adam ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: stupid question: how can I finish a program? [not found] <c923f575.0208130627.479e0b3d@posting.google.com> 2002-08-13 14:37 ` stupid question: how can I finish a program? chris.danx 2002-08-13 14:38 ` David C. Hoos @ 2002-08-14 6:41 ` Emil Moholth 2002-08-14 14:00 ` Marin D. Condic 2002-08-14 7:37 ` Martin Dowie 3 siblings, 1 reply; 61+ messages in thread From: Emil Moholth @ 2002-08-14 6:41 UTC (permalink / raw) "drmed" <jonas.gasser@dataflow.ch> wrote in message news:c923f575.0208130627.479e0b3d@posting.google.com... > hi, > Is there a function which quit/exit/end a program? -> whitout using > the signals (like SIGINT ... etc). > Only a one-line function. > thanks > > jonas This is supported as part of the Annex C - Systems programming. C.7.1 (9) The effect of Abort_Task is the same as the abort_statement for the task identified by T. In addition, if T identifies the environment task, the entire partition is aborted, See E.1 So this leaves us with this single line in the main procedure. Ada.Task_Identification.Abort_Task ( T => Ada.Task_Identification.Current_Task ); If some library unit maintains some persistent state extra measures is needed to ensure a correct state before executing the above statement. I would feel a lot more safe if I could ensure termination of all tasks in the partition as part of the partition termination. Then the partition would terminate normally without any such statement. emilm ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: stupid question: how can I finish a program? 2002-08-14 6:41 ` Emil Moholth @ 2002-08-14 14:00 ` Marin D. Condic 0 siblings, 0 replies; 61+ messages in thread From: Marin D. Condic @ 2002-08-14 14:00 UTC (permalink / raw) That would be a good answer except that it doesn't work in all cases. It is possible for tasks to be in a state where they can't be aborted. There are corner cases in the language rules that will prevent the statement you show from terminating the program. MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling Digital. Our Vision is to be the biggest supplier worldwide of digital gateway technology. www.pacemicro.com "Emil Moholth" <emil.moholth@kongsberg.com> wrote in message news:3d59fb69@193.71.169.73... > > This is supported as part of the Annex C - Systems programming. > > C.7.1 (9) The effect of Abort_Task is the same as the abort_statement for > the task identified by T. In addition, if T identifies the environment task, > the entire partition is aborted, See E.1 > > So this leaves us with this single line in the main procedure. > > Ada.Task_Identification.Abort_Task ( > T => Ada.Task_Identification.Current_Task ); > > If some library unit maintains some persistent state extra measures is > needed to ensure a correct state before executing the above statement. I > would feel a lot more safe if I could ensure termination of all tasks in the > partition as part of the partition termination. Then the partition would > terminate normally without any such statement. > > emilm > > ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: stupid question: how can I finish a program? [not found] <c923f575.0208130627.479e0b3d@posting.google.com> ` (2 preceding siblings ...) 2002-08-14 6:41 ` Emil Moholth @ 2002-08-14 7:37 ` Martin Dowie 3 siblings, 0 replies; 61+ messages in thread From: Martin Dowie @ 2002-08-14 7:37 UTC (permalink / raw) "drmed" <jonas.gasser@dataflow.ch> wrote in message news:c923f575.0208130627.479e0b3d@posting.google.com... > hi, > Is there a function which quit/exit/end a program? -> whitout using > the signals (like SIGINT ... etc). > Only a one-line function. I think this may have been covered in cla a few times (Dec 2000?) but you could do something like: package Program is procedure Kill; end Program; with Ada.Task_Identification; use Ada.Task_Identification; package body Program is Environment_Task : Task_ID := Current_Task; procedure Kill is begin Abort_Task (T => Environment_Task); end Kill; end Program; then call "Program.Kill" from pretty much anywhere else in your program. ^ permalink raw reply [flat|nested] 61+ messages in thread
end of thread, other threads:[~2002-09-02 21:02 UTC | newest] Thread overview: 61+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <c923f575.0208130627.479e0b3d@posting.google.com> 2002-08-13 14:37 ` stupid question: how can I finish a program? chris.danx 2002-08-13 23:53 ` Robert C. Leif 2002-08-14 2:07 ` Wes Groleau 2002-08-14 5:53 ` Robert C. Leif 2002-08-14 13:30 ` Wes Groleau 2002-08-14 13:56 ` Marin D. Condic 2002-08-17 15:58 ` Robert Dewar 2002-08-14 19:18 ` Simon Wright 2002-08-15 14:02 ` Wes Groleau 2002-08-15 1:47 ` Robert Dewar 2002-08-15 5:14 ` Michael Bode 2002-08-17 14:28 ` Alfred Hilscher 2002-08-15 5:17 ` tmoran 2002-08-15 18:41 ` Robert Dewar 2002-08-14 13:53 ` Marin D. Condic 2002-08-15 17:39 ` tmoran 2002-08-16 13:46 ` Marin D. Condic 2002-08-17 14:26 ` Warren W. Gay VE3WWG 2002-08-22 19:16 ` tmoran 2002-08-22 20:54 ` Marin D. Condic 2002-08-25 2:22 ` Robert Dewar 2002-08-26 15:59 ` Marin D. Condic 2002-08-27 21:59 ` Robert A Duff 2002-08-28 20:40 ` Dmitry A.Kazakov 2002-08-28 13:59 ` Robert A Duff 2002-08-28 16:55 ` Darren New 2002-08-28 18:36 ` Larry Kilgallen 2002-08-28 22:22 ` Robert A Duff 2002-08-28 22:30 ` Darren New 2002-08-28 23:16 ` Robert A Duff 2002-08-29 16:49 ` Warren W. Gay VE3WWG 2002-08-29 18:55 ` Larry Kilgallen 2002-08-29 19:17 ` Warren W. Gay VE3WWG 2002-08-30 8:09 ` Ole-Hjalmar Kristensen 2002-08-31 20:39 ` Warren W. Gay VE3WWG 2002-08-29 16:35 ` Dennis Lee Bieber 2002-08-29 22:48 ` Dmitry A.Kazakov 2002-08-29 15:18 ` Robert A Duff 2002-08-30 4:29 ` Dmitry A.Kazakov 2002-08-29 16:53 ` Warren W. Gay VE3WWG 2002-08-29 19:03 ` Robert C. Leif 2002-08-29 19:25 ` Warren W. Gay VE3WWG 2002-08-29 20:42 ` Larry Kilgallen 2002-08-29 20:22 ` Robert A Duff 2002-08-30 20:59 ` Simon Wright 2002-08-28 14:33 ` Marin D. Condic 2002-08-28 22:15 ` Larry Kilgallen 2002-08-29 15:30 ` Robert A Duff 2002-08-29 22:16 ` Dmitry A.Kazakov 2002-08-29 13:17 ` Marin D. Condic 2002-08-29 19:32 ` Robert A Duff 2002-08-31 2:40 ` Dmitry A.Kazakov 2002-08-31 0:10 ` Toshitaka Kumano 2002-09-02 21:02 ` Dmitry A.Kazakov 2002-08-29 16:59 ` Warren W. Gay VE3WWG 2002-08-29 18:26 ` Marin D. Condic 2002-08-13 14:38 ` David C. Hoos 2002-08-13 20:08 ` Adam Beneschan 2002-08-14 6:41 ` Emil Moholth 2002-08-14 14:00 ` Marin D. Condic 2002-08-14 7:37 ` Martin Dowie
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox