Re: stupid question: how can I finish a program?

["Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca>]

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