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-29 10:55:12 PST
Path: 
 archiver1.google.com!news1.google.com!newsfeed.stanford.edu!bloom-beacon.mit.edu!iad-peer.news.verio.net!news.verio.net!washdc3-snh1.gtei.net!chcgil2-snf1.gtei.net!news.gtei.net!news.binc.net!kilgallen
From: Kilgallen@SpamCop.net (Larry Kilgallen)
Newsgroups: comp.lang.ada
Subject: Re: stupid question: how can I finish a program?
Date: 29 Aug 2002 12:55:10 -0600
Organization: LJK Software
Message-ID: <MN6naJHBaAtm@eisner.encompasserve.org>
References: <mailman.1029282843.28085.comp.lang.ada@ada.eu.org>
 <ajdnck$k12$1@nh.pace.co.uk>
 <5ee5b646.0208241822.34540e8b@posting.google.com>
 <wccwuqcyncn.fsf@shell01.TheWorld.com>
 <aki1tq$1ij38n$1@ID-77047.news.dfncis.de>
 <wccptw3hyo2.fsf@shell01.TheWorld.com> <3D6D00B9.60EECCFB@san.rr.com>
 <wccu1letygv.fsf@shell01.TheWorld.com> <3D6D4F44.4872BCFA@san.rr.com>
 <wccit1utvz4.fsf@shell01.TheWorld.com> <3D6E507E.7010805@cogeco.ca>
NNTP-Posting-Host: eisner.encompasserve.org
X-Trace: grandcanyon.binc.net 1030642614 16736 192.135.80.34 (29 Aug 2002
 17:36:54 GMT)
X-Complaints-To: abuse@binc.net
NNTP-Posting-Date: Thu, 29 Aug 2002 17:36:54 +0000 (UTC)
Xref: archiver1.google.com comp.lang.ada:28566
Date: 2002-08-29T12:55:10-06:00
List-Id: <comp.lang.ada>

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 ?