Re: terminate applications

["Randy Brukardt" <randy@rrsoftware.com>]

"Marin David Condic" <nobody@noplace.com> wrote in message
news:3F1E7E1E.8090302@noplace.com...
> What's wrong with the nothion of having a "Standard Ada Library" that
> provides all these sorts of utilities? Why shouldn't it be done in a
> Standard Ada Way instead of a Standard C Way? Why shouldn't Ada aim at
> providing every capability you find in other languages - and then some -
> in order to be the One-Stop Shopping source for the developer?

I would be extremely opposed to any standard "library" functions which
allowed you to end-run finalization. Indeed, I'd be extremely opposed to
*anything* standard that allowed you to end-run finalization.

Finalization is the key to building maintainable abstractions, and we simply
cannot allow cases in which that finalization does not happen. You might
say, "well, the program is going away anyway. Why do we care if the heap is
consistent?" Of course, we don't care of the heap is consistent. But we do
care that resources that the operating system either does not know about, or
does not recover for some reason, are returned.

One odd example is that calling the Win32 Exit_Process on some Windows
systems can leave open files permanently locked until the next reboot. If
the file is something important (say the body of Text_IO), it can leave your
computer unusable.

A more realistic example is interrupt handlers on Windows 95/98. If you
install a handler on those systems, you had better remove if before the
program exits. Otherwise, the system will crash the next time that interrupt
is triggered.

In both of these cases, the problem can be cleared up by the big red power
switch. But we certainly don't need a subprogram that effectively requires
hitting the power switch afterwards.

Of course, finalization also can be used for security purposes (logging out
of a system) as well as to prevent other problems.

The Win32 documentation for Exit_Process suggests that it should not be
called, because it could leave the OS in an inconsistent state. I don't
think we want to make it easier to do things that ought to be avoided in the
first place.

As a vendor, I do not want to be forced, by the inclusion of a poorly
defined "Halt" function (which would be very confusing to our users, as we
already have a safe-ish "Halt" function), to eliminate all finalization from
our run-time, and especially, to be forced to eliminate useful functionality
from the run-time. The Janus/Ada Halt runs all finalization before exists,
similarly to Aborting the environment task. But then there doesn't seem to
be much benefit to having it at all. (We needed it in Ada 83 because you
couldn't abort the environment task - it had no name.)

If your program hangs when you abort the environment task, it has a bug.
That bug should be fixed, because it probably can occur on a normal exit as
well. (And if it is a bug in your compiler, you should report it and they
ought to fix it.)

I don't think that we would be willing to take on the liability (for
possible security failures) and increased support costs involved with having
such a function. Especially since it really is only useful on a program
which is already hung -- at which point you need an outside force to do the
killing anyway.

                                 Randy.