From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,f6ee8ca03c176d76 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-08-17 07:26:14 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!feed.cgocable.net!read2.cgocable.net.POSTED!53ab2750!not-for-mail Message-ID: <3D5E5D05.4040806@cogeco.ca> From: "Warren W. Gay VE3WWG" User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0rc2) Gecko/20020618 Netscape/7.0b1 X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: stupid question: how can I finish a program? References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Date: Sat, 17 Aug 2002 10:26:13 -0400 NNTP-Posting-Host: 24.150.168.167 X-Complaints-To: abuse@cogeco.ca X-Trace: read2.cgocable.net 1029594440 24.150.168.167 (Sat, 17 Aug 2002 10:27:20 EDT) NNTP-Posting-Date: Sat, 17 Aug 2002 10:27:20 EDT Organization: Cogeco Cable Xref: archiver1.google.com comp.lang.ada:28171 Date: 2002-08-17T10:26:13-04:00 List-Id: 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