Re: terminate applications

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

"Randy Brukardt" <randy@rrsoftware.com> wrote in message news:vhu27v687nsdc8@corp.supernews.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.

One of the reasons that kill -9 exists under UNIX is because of
"finalization" type activities that can hang a process. What I mean
is that you can sometimes kill a process, and then watch it hang as
it performs C atexit() processing. After a hang of this type,
you then only have two choices:

  1. Leave it alone (ignore it)
  2. Pull out the kill -9 with extreme prejudice

However, kill -9 can have nasty effects under UNIX. For example, under
SCO UNIX, I have seen tape device drivers get hung this way for a
tape backup. This renders that tape device unusable until the next
reboot, since there are no external ways to unravel the problem.

Likewise, your example of a win32 process leaving the system unstable. I
would maintain that the win32 kernel should take care of disconnecting
the interrupt handler, but even that may not be enough (a null or
invalid interrupt handler may still leave the system unstable)

Consequently I think there are two sides to termination:

 - for some apps, you don't want finalization (kill -9 approach)
 - for others, it will be always/sometimes necessary

It really comes down to the nature of the application and the design
choices made. The criticality of the application is of course, another
factor in the choice.

> 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.

Personally, I believe many of the instances of this problem are due to
M$ laziness in getting things right. Sure, there will be some cases that
are unsolvable (perhaps device driver issues). UNIX kernels are much more
meticulous about what they clean up after a process exit, including
semaphores if the SEM_UNDO features are exploited, IMHO.

> 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.)

To solve MDC's problem, and all that is needed is a sufficiently rounded
GPLed Halt package, that applies to popular platforms. That leaves the
vendors off of the hook, leaves it out of the standards process, and gives
the users the empowerment to do as they please. This package need be
nothing more than a very small binding. Or perhaps a GNAT.Halt
package ;-)

> 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 would generally agree with this, but it may turn out that the bug is
in the O/S handling of the event- in which case, a bigger hammer might
be required.

Warren.
-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg