Re: terminate applications

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

Larry Kilgallen wrote:
> In article <81xWa.6321$mv6.1060816@news20.bellglobal.com>, "Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> writes:
>>I would suggest that you would take the exit that does _NOT_
>>invoke any user mode exit handlers. Otherwise, you would back
>>to doing the equivalent of a normal "kill" with the possibility
>>that the C atexit() or Ada finalization could hang, and still
>>not accomplish the "dirty deed, done dirt cheap."  I don't know,
>>but it would seem almost like VMS might do the atexit()
>>processing using this "user mode exit". (is this true?)
> 
> I am not an expert in C, but I was talking about a user mode exit
> handler, not a user mode exit (which I infer would be something
> like a "user exit" on MVS).

My memory of MVS is much too hazy now ;-)

>>I would expect, that you wouldn't want to tamper with the rest.
>>
>>File integrity.. Who cares?
> 
> Those two statements are in conflict.

How so? I mean, I don't want to start disconnecting parts of
the kernel.  The objective is to effectively terminate the
process and its threads (at least traditional processes and
threads. So these are independant points, and devoid of conflict.

That is:

  - Don't change the kernel settings (exits)
  - Don't worry about file integrity (nobody cares in this case,
    or they wouldn't take such a nasty exit).

>>Remember, the objective is just to "kill that dang thing". The
>>OP did ask for any other guarantees except that the process
>>and its threads be terminated (preferably without taking the
>>whole O/S with it).
> 
> Lots of Original Posters here ask for the simple ability to have the
> Ada operators have exactly the same syntax as C operators. 

That may be, but not in this "halt" discussion.

> I was
> under the impression the goal was to consider a feature that would be
> generally useful, rather than one that exactly matched someone's initial
> wording in a newsgroup post.

Everyone keeps trying to complicate a very simple requirement:

  - terminate with prejudice:
     - process
     - and all accompanying threads
     - no other guarantees requested or desired

if I may paraphrase MDC's request.

Remember we are discussing a suggested way of doing something in
a more-or-less standard way, that doesn't currently exist.

Your heart is in the right place: I mean, it might be desireable
to have an option to select a dump or not. The danger however, is
that as soon as you start adding more "nice to haves", you can
complicate the request to the point where it cannot be done
portably, or without general agreement.

If you asked the OP if he would have to have a "dump" capability
in order to proceed, I expect that he would dump that requirement
in order to get the most important thing -- namely that which I
paraphrased above.

So yes, it is good to be general, but don't kill by insisting
on too much. ;-)

>>The programmer is using this API because he has weighed the risk
>>of doing so, and has decided that it is going to be done. If
>>not, then he gets what he deserves ;-)  Insisting on file
>>integrity is to add policy to the original request.
> 
> I will take your word for it that file integrity is not a big deal
> in some environments, but there are others where it is.

Absolutely! But if file integrity is a concern, then you should
not be doing this kind of thing; or at least you should be
certain that your writes are flushed, and files closed before you
pull the plug.

>>Not being familiar with VMS, I cannot answer the other question, since
>>there seems to be an implied difference between program and process.
>>
>>What does a "program" mean in a VMS environment?  Under UNIX/Windoze,
>>we talk of processes and threads.  What is DCL?
> 
> A process is an execution environment.  For instance, when you log
> into a VMS system a process is created.  DCL (Digital Command Language)
> commands you issue successively run various programs, by default in the
> context of that process.

Are you saying that the environment + command run in one address
space together? It sounds a bit like DOS command interpreter and
executable living in the same address space together.

> In some environments it is quite rude to terminate a process (rather than
> just the program running within that process) since the very next step
> (in a command procedure being run in that process, for example) may be
> to indicate an error condition to the operator on duty, or in more primitive
> environments, email any error indication to some other human being.

Agreed, but I would suggest that it is also rude
to leave a hung process and threads running, eating 100% of the CPU
with no way to terminate it.

It is also rude to the user, to expect him to individually kill
off 20 threads every time the program fails to terminate ;-)

Finally, it is ruder still to run a program with no way to
cancel it 8-)

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