terminate applications

terminate applications

[Riccardo]

is present a function that terminated applications?
if yes what's?

for example: exit(0); // language C
thanks
bye

Re: terminate applications

[Nick Roberts]

"Riccardo" <rfulcoli@amsjv.it> wrote in message
news:bf5uks$8n0$1@e3k.asi.ansaldo.it...

> is present a function that terminated applications?
> if yes what's?
>
> for example: exit(0); // language C

You should transfer control to the end of the main subprogram. For example:

   with Ada.Text_IO;
   procedure Main is
      Count: Natural := 0;
      procedure Some_Inner_Procedure is
         use Ada.Text_IO;
      begin
         Put_Line("Hello World");
         if Count = 100 then
            -- we want to terminate program here
            goto End_of_Program;
         end if;
      end Some_Inner_Procedure;
   begin
      loop
         Some_Inner_Procedure;
         Count := Count + 1;
      end loop; -- infinite loop
   <<End_of_Program>> -- this is how you write a goto label in Ada
   end Main;

This example doesn't necessarily show the most elegant technique, but it is
generally acceptable, and illustrates the idea.

Of course, the best technique is always to let the program flow naturally to
the end of the main subprogram, if it is reasonable to do so. To illustrate
this, the above example would certainly be better rewritten like this:

   with Ada.Text_IO;
   procedure Main is
      procedure Some_Inner_Procedure is
         use Ada.Text_IO;
      begin
         Put_Line("Hello World");
      end Some_Inner_Procedure;
   begin
      for i in 1..100 loop
         Some_Inner_Procedure;
      end loop;
   end Main;

I think it is quite important that, normally, you do not use any other
method to terminate an Ada program, since using another method could prevent
library packages (e.g. Ada.Text_IO, used in my examples) from finalizing
('cleaning up') properly.

PS: Would the above be suitable for submission to OSnippets in the Ada
category?

--
Nick Roberts
Jabber: debater@charente.de [ICQ: 159718630]

Re: terminate applications

[Mark A. Biggar]

Nick Roberts wrote:
> "Riccardo" <rfulcoli@amsjv.it> wrote in message
> news:bf5uks$8n0$1@e3k.asi.ansaldo.it...
> 
> 
>>is present a function that terminated applications?
>>if yes what's?
>>
>>for example: exit(0); // language C
> 
> 
> You should transfer control to the end of the main subprogram. For example:
> 
>    with Ada.Text_IO;
>    procedure Main is
>       Count: Natural := 0;
>       procedure Some_Inner_Procedure is
>          use Ada.Text_IO;
>       begin
>          Put_Line("Hello World");
>          if Count = 100 then
>             -- we want to terminate program here
>             goto End_of_Program;
>          end if;
>       end Some_Inner_Procedure;
>    begin
>       loop
>          Some_Inner_Procedure;
>          Count := Count + 1;
>       end loop; -- infinite loop
>    <<End_of_Program>> -- this is how you write a goto label in Ada
>    end Main;
> 
> This example doesn't necessarily show the most elegant technique, but it is
> generally acceptable, and illustrates the idea.
> 
> Of course, the best technique is always to let the program flow naturally to
> the end of the main subprogram, if it is reasonable to do so. To illustrate
> this, the above example would certainly be better rewritten like this:
> 
>    with Ada.Text_IO;
>    procedure Main is
>       procedure Some_Inner_Procedure is
>          use Ada.Text_IO;
>       begin
>          Put_Line("Hello World");
>       end Some_Inner_Procedure;
>    begin
>       for i in 1..100 loop
>          Some_Inner_Procedure;
>       end loop;
>    end Main;
> 
> I think it is quite important that, normally, you do not use any other
> method to terminate an Ada program, since using another method could prevent
> library packages (e.g. Ada.Text_IO, used in my examples) from finalizing
> ('cleaning up') properly.

If you really need to abort an Ada program form some deeply nested code,
raising an exception is a reaaonable way to do it.  All clean up actions
are guarenteed to happen and you can add a handler to the main procedure
to do any last gasp stuff cleanly.



-- 
mark@biggar.org
mark.a.biggar@comcast.net

Re: terminate applications

[Nick Roberts]

"Mark A. Biggar" <mark@biggar.org> wrote in message
news:23ERa.75454$OZ2.12362@rwcrnsc54...

> If you really need to abort an Ada program form some
> deeply nested code, raising an exception is a reasonable
> way to do it.  All clean up actions are guaranteed to
> happen and you can add a handler to the main procedure
> to do any last gasp stuff cleanly.

Absolutely right.

Furthermore, on reviewing the first example I gave, I see that it is
rubbish! You cannot 'goto' out of a procedure in Ada. Sorry.

Perhaps it could be corrected to the following:

   with Ada.Text_IO; use Ada.Text_IO;
   procedure exit_from_prog is
      Count: Natural := 0;
      My_Exception: exception;
      procedure Inner_Proc is
      begin
         Put_Line("Hello World");
         if Count = 20 then
            raise My_Exception;
         end if;
      end;
   begin
      loop
         Inner_Proc;
         Count := Count + 1;
      end loop;
   exception
      when My_Exception =>
         Put_Line("Clean termination!");
      when others =>
         Put_Line("Something unexpected!");
   end;

I have tested this on GNAT!

The second example, and the reason why it is better, remains correct.

--
Nick Roberts
Jabber: debater@charente.de [ICQ: 159718630]

Re: terminate applications

[sk]

Maybe this is what you are looking for ?

(GNAT 3.15p, Linux)

-- <begin> hello.adb --
with Ada.Text_Io;

procedure Hello is

         Exit_Now : Boolean := True;

begin

         if Exit_Now then

                 Ada.Text_Io.Put_Line ("Exiting now !");

                 return;

         end if;

         -- Some other processing ...

         Ada.Text_Io.Put_Line ("Exiting later ...");

end Hello;

-- <end> hello.adb --

-- 
-------------------------------------------------
-- Merge vertically for real address
--
--     s n p @ t . o
--      k i e k c c m
-------------------------------------------------

Re: terminate applications

[christoph.grein]

All the methods shown so far work only on a non-tasking program, and then it is 
easy to terminate the application. Ada also has (in package Command_Line) a 
procedure to set the exit status.

But beware when you use tasking:

  with Something;
  procedure Main is
    task Work;
  begin
    ...
    ... raise Some_Exc;
    ...
  exception
    when Some_Exc => null;  -- terminate now
  end Main;

When Some_Exc is raised, Main (the main task) waits for termination of 
subordinate tasks. So if you stop the main task via an exception the program 
will happily go on if there are other tasks (e.g. task Work or library tasks in 
Something) still running.

A common way to write a tasking application is to have a main program without 
any declarations and with a null statement:

  with Something;
  procedure Main is
  begin
    null;
  end Main;

All the work is done in Something.

You face the complicated problem how to terminate all these dependent tasks. 
Raising an exception in one task will silently terminate the task without 
informing any other task (except when in rendez-vous).

To find a solution for this problem is not easy. It depends on your application 
and has to be designed by you. You could use the abort statement, but there are 
abort-deferred regions...

In C there is no built-in tasking so (AFAIK) exiting a program with a call to 
exit(0) is easy (as as easy as in Ada if you have no tasking).

What you have to do if you are running threads in C, I do not know. Perhaps then 
the problem is similar.

Re: terminate applications

[Jeffrey Creem]

This is not something I usually have to worry about because almost
everything I do is embedded stuff
but when I am doing little non embedded programs and I want to kill the
program (especially when
making  use of embedded packages that have no real facilities for shutting
down their tasks) I usuallly
just terminate the environment task. The package below provides a procedure
that when called from
anywhere (either main task or any other task) will terminate the environment
task and shut down the
program.

The real answer is that when writing well behaved multi-tasking programs,
one needs to provide nice shutdown
facilities for all the tasks....but this terminator approach works for the
quick and dirty case.


package Arnold is

procedure Terminator;

end Arnold;



with Ada.Task_Identification;

pragma Elaborate_All(Ada.Task_Identification);





package body Arnold is

Environment_Task_Id : Ada.Task_Identification.Task_Id :=
Ada.Task_Identification.Current_Task;

procedure Terminator is

begin

Ada.Task_Identification.Abort_Task(Environment_Task_Id);

end Terminator;

end Arnold;

Re: terminate applications

[Marin David Condic]

Terminating the environment task is supposed to be a legitimate method 
of killing everything, but I've had problems getting it to work with 
GNAT on a PC platform. What compiler do you use on which this works 
reliably?

MDC

Jeffrey Creem wrote:

> 
> package body Arnold is
> 
> Environment_Task_Id : Ada.Task_Identification.Task_Id :=
> Ada.Task_Identification.Current_Task;
> 
> procedure Terminator is
> 
> begin
> 
> Ada.Task_Identification.Abort_Task(Environment_Task_Id);
> 
> end Terminator;
> 
> end Arnold;
> 
> 
> 
> 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jast.mil/

Send Replies To: m c o n d i c @ a c m . o r g

     "In general the art of government consists in taking as
     much money as possible from one class of citizens to give
     to the other."

         --  Voltaire
======================================================================

Re: terminate applications

[Nick Roberts]

"Marin David Condic" <nobody@noplace.com> wrote in message
news:3F17DF3C.4080204@noplace.com...

> Terminating the environment task is supposed to be a
> legitimate method of killing everything, but I've had
> problems getting it to work with GNAT on a PC
> platform.

The problem, I suspect, is even worse if your entire program is composed of
multiple partitions, since each partition has its own environment task.

--
Nick Roberts
Jabber: debater@charente.de [ICQ: 159718630]

Re: terminate applications

[Jeffrey Creem]

"Marin David Condic" <nobody@noplace.com> wrote in message
news:3F17DF3C.4080204@noplace.com...
> Terminating the environment task is supposed to be a legitimate method
> of killing everything, but I've had problems getting it to work with
> GNAT on a PC platform. What compiler do you use on which this works
> reliably?
>
> MDC
>
>

I've done it under Solaris (GNAT) and Windows XP (GNAT 3.15p). I can not say
that I have tried it under all combinations of programs (OS calls,
partitions, etc)..but it works for the cases I have tried.

Re: terminate applications

[Marin David Condic]

I've got a program that was busy doing a variety of things including 
network I/O with winsock calls. In most prior versions of Gnat, it 
wouldn't terminate when killing the environment task. I have not checked 
it with the latest version of Gnat, so I don't know that it is still 
broke. It was too difficult to isolate the exact combination of 
circumstances that kept it from getting killed, so I couldn't make a 
simple example program without way too much effort. Since it is not a 
"Mission Critical" application, I settled for terminating it with a 
control-C instead of trying to fix it. Too bad the compiler can't 
recognize terminating the environment task as a special case and 
duplicate the behavior of the control-C.

MDC



Jeffrey Creem wrote:
> 
> I've done it under Solaris (GNAT) and Windows XP (GNAT 3.15p). I can not say
> that I have tried it under all combinations of programs (OS calls,
> partitions, etc)..but it works for the cases I have tried.
> 
> 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jast.mil/

Send Replies To: m c o n d i c @ a c m . o r g

     "In general the art of government consists in taking as
     much money as possible from one class of citizens to give
     to the other."

         --  Voltaire
======================================================================

Re: terminate applications

[Robert I. Eachus]

Marin David Condic wrote:
> I've got a program that was busy doing a variety of things including 
> network I/O with winsock calls. In most prior versions of Gnat, it 
> wouldn't terminate when killing the environment task. I have not checked 
> it with the latest version of Gnat, so I don't know that it is still 
> broke. It was too difficult to isolate the exact combination of 
> circumstances that kept it from getting killed, so I couldn't make a 
> simple example program without way too much effort. Since it is not a 
> "Mission Critical" application, I settled for terminating it with a 
> control-C instead of trying to fix it. Too bad the compiler can't 
> recognize terminating the environment task as a special case and 
> duplicate the behavior of the control-C.

I don't see why it should. It is a level of abstraction problem.  If the 
OS has threads that are "uninterruptable," that should be treated just 
like an abort-deferred region in Ada.

So as I see it, what is happening is that you abort the environment 
task, which aborts all other tasks in the environment.  But if one task 
can be stuck in an abort deferred mode you need your code to deal 
explicitly with that situation.  And AFAIK, there are a few cases in 
Windows where you need the OS to do it for you.

This is a difference between Ada 83 and Ada 95.  In Ada 83 abort was 
efectively absolute.  If you aborted the environment task, all other 
tasks were also aborted.  Due to the asymmentric nature of the rules, 
the calling task in a rendezvous was aborted first, but they were both 
aborted.

In RM 9.8(6-11) there is a list of the abort deferred regions:

* a protected action;

* waiting for an entry call to complete (after having initiated the 
attempt to cancel it -- see below);

* waiting for the termination of dependent tasks;

* the execution of an Initialize procedure as the last step of the 
default initialization of a controlled object;

* the execution of a Finalize procedure as part of the finalization of a 
controlled object;

* an assignment operation to an object with a controlled part.

The two cases with serious gotcha! potential are putting a blocking call 
by the CPU inside a protected object, and a Finalize procedure that can 
do the same thing. (Calls to Initialize and Adjust can do the same 
thing, but terminating tasks is going to finalize all existing objects.)

RM section 9.5.1 (8-18) has a list of the ways you can shoot yourself in 
the foot within a protected object.

-- 

                                                        Robert I. Eachus

�In an ally, considerations of house, clan, planet, race are 
insignificant beside two prime questions, which are: 1. Can he shoot? 2. 
Will he aim at your enemy?� -- from the Laiden novels by Sharon Lee and 
Steve Miller.

Re: terminate applications

[Marin David Condic]

Interesting, but not compelling because it just plain isn't terribly 
useful to the end user. If I want a simple call to shoot the entire 
program in the head, I don't want to study the Suma Theologica for 
several years to figure out what programming sin I committed that is 
keeping it from doing the thing I want done. :-) If there is some 
Theoretical Purity that must be maintained to task abortion, then so be 
it. Give me a Ada.Kill ("-9") ; subprogram call that will do what I want 
it to do - kill the program regardless of what the rest of it may be doing.

All too often, Ada gets herself wrapped up in trying to maintain some 
sort of purity on some issue and totally forgets that someone out there 
needs a job done. Just like my desire to get saturated math gets shot 
down by those who insist its behavior is too ill defined for the 
standard. So what? Let it be ill defined. Its use in reality has 
beneficial effects as an error recovery mechanism. It gets used in 
reality all the time. All Ada succeeds in doing by maintaining this 
purity is to make itself less useful to the practitioner - who must now 
find some butt-ugly way around the problem.

MDC

Robert I. Eachus wrote:
> 
> 
> I don't see why it should. It is a level of abstraction problem.  If the 
> OS has threads that are "uninterruptable," that should be treated just 
> like an abort-deferred region in Ada.
> 
-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jast.mil/

Send Replies To: m c o n d i c @ a c m . o r g

     "In general the art of government consists in taking as
     much money as possible from one class of citizens to give
     to the other."

         --  Voltaire
======================================================================

Re: terminate applications

[Robert I. Eachus]

Marin David Condic wrote:
> Interesting, but not compelling because it just plain isn't terribly 
> useful to the end user. If I want a simple call to shoot the entire 
> program in the head, I don't want to study the Suma Theologica for 
> several years to figure out what programming sin I committed that is 
> keeping it from doing the thing I want done. :-) If there is some 
> Theoretical Purity that must be maintained to task abortion, then so be 
> it. Give me a Ada.Kill ("-9") ; subprogram call that will do what I want 
> it to do - kill the program regardless of what the rest of it may be doing.

First, send a comment to Ada-Comment.  I believe the address is 
currently ada-comment@ada-auth.org.  I think you have a good case for 
some sort of an �berkill.

But note that this cannot and should not be the normal behaviour of 
aborting the environment task, or any task.  This is not ideological 
purity.  Think of it this way.  Using your �berkill on a program that 
interfaces to a database will not only kill the program, it will break 
transactions and corrupt the database.  Yes, cycling the power can do 
the same thing, but correctly written Ada programs will not, even if the 
main program is aborted.  (It will of course abort transactions in 
progress, which is fine.  But the (correct) use of abort deferred 
regions will allow the main program to be aborted cleanly without 
corrupting any external files.

So why provide your hypothetical �berkill?  Because programmers are 
human, programs have errors, especially during development.  And it 
would be really nice to have the �berkill so you could fix the error. 
(It would be nice if you got an error message telling you where the 
abort was hanging, but the debugger should give you that.)

> All too often, Ada gets herself wrapped up in trying to maintain some 
> sort of purity on some issue and totally forgets that someone out there 
> needs a job done. Just like my desire to get saturated math gets shot 
> down by those who insist its behavior is too ill defined for the 
> standard. So what? Let it be ill defined. Its use in reality has 
> beneficial effects as an error recovery mechanism. It gets used in 
> reality all the time. All Ada succeeds in doing by maintaining this 
> purity is to make itself less useful to the practitioner - who must now 
> find some butt-ugly way around the problem.

If you think there is that kind of shootdown, send your complaint, 
again, to Ada-Comment.  But there is not.  I would love to see an 
addition to Ada 0Y that made saturated math easier, and I think it can 
be made to happen.  But the process is that real users (you) send in 
requirements indicating real needs, and the ARG will try to propose a 
language extension to WG9 that satisfies that need.

In the case of saturated arithmetic, that might be a predefined 
saturated type, or it could be a solution to the problem of literals for 
otherwise private types, say:

    type Saturated is private range <>;
    type Modular  is private mod <>;
    type Rational is private digits <>;
or type Rational is private delta <>;

which would get rid of the predefined operations (other than assignment 
and equality) but keep the literals.  How would users tell the compiler 
how to map the literals into values?  That is the tricky part.

-- 

                                                        Robert I. Eachus

�In an ally, considerations of house, clan, planet, race are 
insignificant beside two prime questions, which are: 1. Can he shoot? 2. 
Will he aim at your enemy?� -- from the Laiden novels by Sharon Lee and 
Steve Miller.

Re: terminate applications

[Marin David Condic]

Sure, its possible that an uberkill could leave a database corrupt - 
especially one that didn't properly implement the concept of a 
"transaction" that keeps things pending until there is a "commit". But 
just because one can imagine some corner-case in which an uberkill might 
make a mess of things doesn't mean it shouldn't exist. Sometimes one has 
to trust the programmer not to do something stupid with a language feature.

Yes, a clean shutdown is desirable. I suspect where I have my program 
hanging trying to terminate the environment task is within some OS fault 
- or "feature". But so long as the user has a control-C key on his 
keyboard, there exists the possibility of a direct headshot to a 
program, so it must be possible to do that from under program control. 
People invented those sorts of things for a reason. Sometimes, its a 
good thing to be able to kill some runaway program. Sometimes its 
convenient to say "I'm done with you now and I don't care what you're 
doing, just stop and go away...." Perhaps programs of better (or at 
least different) design might not require such a feature, but that 
doesn't mean it shouldn't exist.

I know Ada tends to dislike features that might in some way be 
"dangerous", but absolute safety is for people who don't have the 
testicular fortitude to live in the real world. :-) It is probably wise 
not to have the ability to create pointers capabile of pointing to 
anything because it is "dangerous" - but mostly because the programmer 
doesn't really have much need to do so. Alternatives exist and only 
someone stuck in a C idiom would find it difficult to get the job done 
without it. But when programming a cruise missile, sooner or later you 
need to execute the "Ignite the explosives" instruction and pretty much 
by definition, that's "dangerous". ;-) Ada should have one of those 
instructions or its tough to break into the cruise missile business.

MDC



Robert I. Eachus wrote:
> 
> But note that this cannot and should not be the normal behaviour of 
> aborting the environment task, or any task.  This is not ideological 
> purity.  Think of it this way.  Using your �berkill on a program that 
> interfaces to a database will not only kill the program, it will break 
> transactions and corrupt the database.  Yes, cycling the power can do 
> the same thing, but correctly written Ada programs will not, even if the 
> main program is aborted.  (It will of course abort transactions in 
> progress, which is fine.  But the (correct) use of abort deferred 
> regions will allow the main program to be aborted cleanly without 
> corrupting any external files.
> 

-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jast.mil/

Send Replies To: m c o n d i c @ a c m . o r g

     "In general the art of government consists in taking as
     much money as possible from one class of citizens to give
     to the other."

         --  Voltaire
======================================================================

Re: terminate applications

[Robert I. Eachus]

Marin David Condic wrote:
> Ada should have one of those  instructions or its tough to break into the
 > cruise missile business.

Hmmmm.  I was thinking of an implementation of the "kill -9" idiom that 
did not involve a few hundred pounds of high-explosive.  Something like:

abort; -- the environment task;
delay 3.0;
kill -9;

Of course, I can't express the real semantics in Ada, since the abort of 
the environment task will make all tasks abnormal, then the delay 
starts.  In Ada of course, the event of the timer expiring would never 
occur.  Besides if the abort does work, you don't want to wait the three 
seconds.  Maybe I can express it as an ATC:

select
   delay 3.0;
   OS_Call("kill -9");
then abort
   abort;
end select;

Nope, doesn't work.  The abort will complete when all tasks are 
abnormal.  At that point the delay statement can be aborted and the 
OS_Call never gets made...

-- 

                                                        Robert I. Eachus

�In an ally, considerations of house, clan, planet, race are 
insignificant beside two prime questions, which are: 1. Can he shoot? 2. 
Will he aim at your enemy?� -- from the Laiden novels by Sharon Lee and 
Steve Miller.

Re: terminate applications

[Randy Brukardt]

"Marin David Condic" <nobody@noplace.com> wrote in message
news:3F1BD666.6040506@noplace.com...
> Yes, a clean shutdown is desirable. I suspect where I have my program
> hanging trying to terminate the environment task is within some OS fault
> - or "feature". But so long as the user has a control-C key on his
> keyboard, there exists the possibility of a direct headshot to a
> program, so it must be possible to do that from under program control.

For what it's worth, Janus/Ada's runtime tries to trap as many such possible
"headshots" and cause a clean shutdown. We definitely try to trap control-C
(which doesn't always work for some reason that I've never understood).

That has it's roots in our compiler, where it was traditional to kill long
compilations with control-C if they were finding too many errors or some
other problem came up. But a straight kill would leave temporary files and
(worse) partially written object files which could confuse the Make tool.
Thus, we tried very hard to insure that compiles were never aborted without
the clean-up code running.

Of course, there is no recourse to a kill -9 or pulling the plug. But those
should be a really last resort. (Of course, I've never seen a program with a
correct runtime hang when it was aborted. I had some programs do that when
the runtime was screwed up, but no other time. If checks are not suppressed,
I'd consider it a bug.)

                             Randy.

Re: terminate applications

[Marin David Condic]

I'd consider it a bug too. However, I think the compiler writers 
responsible for it consider it a "feature" or at least a "bug" that 
belongs to Windows. It was too difficult to track down the ultimate 
cause for a program that just wasn't that important and could take a 
control-C kill at the point where the abortion of the environment task 
would not work. It just seemed to me that passing the buck around wasn't 
very productive. If one can't make the abortion of the environment task 
work as expected, then come up with an alternative that absolutely, 
positively, double-your-mony-back-if-not-completely-satisfied, *will* 
work. Other programming languages provide some means of program 
termination (Pascal had a "HALT" instruction IIRC...) so its not as if I 
was dreaming up some wild-eyed fanatical scheme from the lunatic fringe. :-)

MDC



Randy Brukardt wrote:
> 
> Of course, there is no recourse to a kill -9 or pulling the plug. But those
> should be a really last resort. (Of course, I've never seen a program with a
> correct runtime hang when it was aborted. I had some programs do that when
> the runtime was screwed up, but no other time. If checks are not suppressed,
> I'd consider it a bug.)
> 

-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jast.mil/

Send Replies To: m c o n d i c @ a c m . o r g

     "In general the art of government consists in taking as
     much money as possible from one class of citizens to give
     to the other."

         --  Voltaire
======================================================================

Re: terminate applications

[Marin David Condic]

Well, possibly the answer is to invent some alternative form of the 
abort wherein we let the compiler writers worry about the timer. Some 
version of "Try to do an orderly shutdown but in the event of a lack of 
successful termination, set off the explosive charges..." At the 
underlying OS level, there are usually sufficient facilities to do this 
- just that it will likely be system dependent & hence better done there 
than at the Ada source level.

I could probably go search through the Win32api and find a "Kill this 
process and I really, really mean it" system call, but a) it would be 
system dependent and b) the program in question is not that important to 
make it worth trying to add a revision at this time. It would just be 
nice to see Ada come up with a better answer.

MDC



Robert I. Eachus wrote:
> 
> Hmmmm.  I was thinking of an implementation of the "kill -9" idiom that 
> did not involve a few hundred pounds of high-explosive.  Something like:
> 
> abort; -- the environment task;
> delay 3.0;
> kill -9;
> 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jast.mil/

Send Replies To: m c o n d i c @ a c m . o r g

     "In general the art of government consists in taking as
     much money as possible from one class of citizens to give
     to the other."

         --  Voltaire
======================================================================

Re: terminate applications

[Arnaud Charlet]

> I could probably go search through the Win32api and find a "Kill this 
> process and I really, really mean it" system call, but a) it would be 

If that's what you're looking for (and it seems indeed pretty clear from
your previous messages), then I'd suggest you ignore the other messages on
this thread, and you do the same as with any other programming language:

procedure Halt;
pragma Import (C, Halt, "exit");

...
Halt;

and be done with it.

Starting to discuss about task abortion, synchronization, etc... when all
you need is a brutal program shutdown is not very productive, in
particlar since this issue comes up regularly on this newsgroup, with
almost always the same answers, which make Ada look like a beautiful but
useless language :-)

Arno

Re: terminate applications

[Marin David Condic]

Ahhhh, but now we are dependent on C to do the work for us and all the 
Ada critics will rightly say "See?!?!?! Ada just isn't as popwerful as C 
is!!!" :-) And then we're back to the "Well, you can always build a 
binding to Language XYZ's library of really useful stuff....." argument 
that has Ada forever playing "Catch Up" to other languages and fails to 
persuade people to use Ada.

If you can do something like this in C, why shouldn't Ada have the same 
facility?

MDC



Arnaud Charlet wrote:
> 
> procedure Halt;
> pragma Import (C, Halt, "exit");
> 
> ...
> Halt;
> 
> and be done with it.

-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jast.mil/

Send Replies To: m c o n d i c @ a c m . o r g

     "In general the art of government consists in taking as
     much money as possible from one class of citizens to give
     to the other."

         --  Voltaire
======================================================================

Re: terminate applications

[Lutz Donnerhacke]

* Arnaud Charlet wrote:
>> I could probably go search through the Win32api and find a "Kill this 
>> process and I really, really mean it" system call, but a) it would be 
> 
> If that's what you're looking for (and it seems indeed pretty clear from
> your previous messages), then I'd suggest you ignore the other messages on
> this thread, and you do the same as with any other programming language:
> 
> procedure Halt;
> pragma Import (C, Halt, "exit");
> 
> ...
> Halt;
> 
> and be done with it.

That will start a clean shutdown of the libc. You don't won't that.

with Kernel.Processes;
[...]
   procedure Halt renames Kernel.Processes.sysexit;
   [...]
   Halt;

This is the right way! Read the spec:
   --  NAME
   --         exit - terminate the current process
   --  SYNOPSIS
   --         void _exit(int status);
   procedure sysexit (return_code : exit_code_t);
   --# global in out Kernel.State;
   --# derives Kernel.State from Kernel.State, return_code;
   pragma Inline_Always (sysexit);

and the implementation:

separate (Kernel.Processes)
procedure sysexit(return_code : exit_code_t) is
   UnusedRes : Linux_i86.syscall_result;
begin
   Linux_i86.syscall1(Linux_i86.sys_exit, long(return_code), UnusedRes); --! Assignment to UnusedRes is ineffective.
end sysexit; --! The variable UnusedRes is neither referenced nor exported.

and the exception freedom proof:

procedure_sysexit_1.
H1:  true.
H2:  return_code >= exit_code_t__first.
H3:  return_code <= exit_code_t__last.
        ->
C1:  return_code >= kernel__linux_i86__long__first.
C2:  return_code <= kernel__linux_i86__long__last.
C3:  kernel__linux_i86__sys_exit >= kernel__linux_i86__syscall_number__first.
C4:  kernel__linux_i86__sys_exit <= kernel__linux_i86__syscall_number__last.
C5:  return_code >= long__first.
C6:  return_code <= long__last.
 

*** Rule substitutions phase 1
*** Applied substitution rule sysexit_rules(4)
*** Applied substitution rule sysexit_rules(5)
*** Applied substitution rule sysexit_rules(3)
*** Applied substitution rule sysexit_rules(9)
*** Applied substitution rule sysexit_rules(10)
*** Applied substitution rule sysexit_rules(14)
*** Applied substitution rule sysexit_rules(15)
*** PROVED C3
*** PROVED C4
*** Rule substitutions phase 2
*** Applied substitution rule sysexit_rules(19)
*** Applied substitution rule sysexit_rules(20)
*** Standardise hypotheses
*** Standardise conclusions
*** PROVED C1
*** PROVED C2
*** PROVED C5
*** PROVED C6
*** Contradiction hunt
*** Proved all conclusions - VC eliminated
*** Expression reduction

          ==================================================

For path(s) from start to finish:

procedure_sysexit_2.
*** true .          /* trivially true VC removed by Examiner */

*** PROVED C1
*** Proved all conclusions - VC eliminated

Automatic simplification completed.

And don't do this with C!

Re: terminate applications

[Arnaud Charlet]

All right, this is a troll, so I won't feed the troll, and this will be
my second and last answer on this issue.

> If you can do something like this in C, why shouldn't Ada have the same 
> facility?

How do you know that "exit" is implemented in C ? It may well be
implemented in Ada, or Assembly, or Fortran, or ?

C uses a binding to the exit function, doing a #include <stdlib.h>,
or extern void exit(); (int parameter intentionally omitted), and Ada
does the same, there is absolutely no difference except in your mind.

And as you will notice, there is no need to say "you can always build a
binding", since the binding is already done, and is as trivial as the C
binding.

The mistake is to try to put one language against another, rather than
associating languages with one another seamlessly.

Arno

Re: terminate applications

[Nick Roberts]

"Marin David Condic" <nobody@noplace.com> wrote in message
news:3F1D27CC.6020002@noplace.com...

> ... Other programming languages provide some means of
> program termination (Pascal had a "HALT" instruction
> IIRC...) so its not as if I was dreaming up some wild-eyed
> fanatical scheme from the lunatic fringe. :-)

What I'd like to see is the Halt procedure having a Reset parameter
(Boolean, in), which, when true, would cause the generation of a localised
temporal inversion vortex (LTIV) -- provided the necessary hardware was
attached, naturally -- just sufficient to completely undo the effects of the
program since the moment it was executed.

It would be necessary for the operating system to trap attempts to extend
the LTIV beyond -15 years, so as to eliminate the possibility of the dreaded
ROTM/JD* effect.

--
Nick Roberts
Jabber: debater@charente.de [ICQ: 159718630]

* Rise of the Machines/Judgment Day**

** sometimes termed in the literature as the GEFBA series***

*** Good Excuse for Bad Acting****

**** although I suppose The Terminator may be just what we're looking for

:-)

Re: terminate applications

[Marin David Condic]

Well, I'm not really trying to troll here - just make a point that if C 
has an answer to a problem and other languages have a similar answer to 
the problem, why shouldn't Ada? If the features in Ada won't do 
something useful that is done in other languages, then maybe we need to 
add a feature that *will* do it.

Here's an analogy: Suppose you own a hardware store and someone comes in 
and says "I want to buy a hammer..." and your response is "Well, hammers 
aren't really safe or the best way to do something. We supply these 
marvelous self-tapping screws with a special, high precision, motorized 
driving unit that will securely fasten these wonderful, furniture-grade 
boards together....". The customer insists "But all I want to do is tack 
down some loose boards on my dog house in the back yard...." You say 
"Well, my competitor across the street sells hammers and nails - go buy 
them from him and then come back here and get my fine furniture grade 
boards..." What is the customer likely to do? Go across the street and 
take *all* of his business there.

If Ada wants to be competitive against C, C++, Java or whatever else is 
out there, it has to be focused on customer needs. It can't be dependent 
on sending the customer to the competitor for features it can't or won't 
support, or the customer just starts to wonder why he is bothering with 
Ada when he has to have the other product anyway in order to get the job 
done. Ada needs to provide "One-Stop Shopping" so a developer doesn't 
need to look elsewhere for an answer.

MDC



Arnaud Charlet wrote:
> All right, this is a troll, so I won't feed the troll, and this will be
> my second and last answer on this issue.
> 
> 
>>If you can do something like this in C, why shouldn't Ada have the same 
>>facility?
> 
> 
> How do you know that "exit" is implemented in C ? It may well be
> implemented in Ada, or Assembly, or Fortran, or ?
> 
> C uses a binding to the exit function, doing a #include <stdlib.h>,
> or extern void exit(); (int parameter intentionally omitted), and Ada
> does the same, there is absolutely no difference except in your mind.
> 
> And as you will notice, there is no need to say "you can always build a
> binding", since the binding is already done, and is as trivial as the C
> binding.
> 
> The mistake is to try to put one language against another, rather than
> associating languages with one another seamlessly.
> 
> Arno
> 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jast.mil/

Send Replies To: m c o n d i c @ a c m . o r g

     "In general the art of government consists in taking as
     much money as possible from one class of citizens to give
     to the other."

         --  Voltaire
======================================================================

Re: terminate applications

[Samuel Tardieu]

>>>>> "Marin" == Marin David Condic <nobody@noplace.com> writes:

Marin> Well, I'm not really trying to troll here - just make a point
Marin> that if C has an answer to a problem and other languages have a
Marin> similar answer to the problem, why shouldn't Ada? If the
Marin> features in Ada won't do something useful that is done in other
Marin> languages, then maybe we need to add a feature that *will* do
Marin> it.

I don't get your point: importing exit() from the standard C library
is not more difficult than instantiating Ada.Unchecked_Dellocation to
reclaim unused memory space. If the programmer really needs this
feature badly, it only takes a few characters to use it.

C, and many other languages, do have the ability of modifying a loop
index within the loop. We do not have this in the Ada "for" loop", but we
can "emulate" this with a varianle and a simple or a "while" loop. The
situation is similar here. If you want to do it, you can, but there is
no need to make it a language construct or a standard library.

  Sam
-- 
Samuel Tardieu -- sam@rfc1149.net -- http://www.rfc1149.net/sam

Re: terminate applications

[Dave Thompson]

On Fri, 18 Jul 2003 11:36:20 +0200 (MET DST),
christoph.grein@eurocopter.com wrote:
<snip>
> In C there is no built-in tasking so (AFAIK) exiting a program with a call to 
> exit(0) is easy (as as easy as in Ada if you have no tasking).
> 
> What you have to do if you are running threads in C, I do not know. Perhaps then 
> the problem is similar.

In POSIX/SUS threads exit() or _Exit() (or abort() or a fatal signal)
in any thread, or returning from main(), terminates the process
including all threads (without threadaware cleanup).  If you
pthread_exit() from the main thread, the process continues until all
threads exit (pthread_exit() or return from the thread function).
You can explicitly coordinate such a multi-thread shutdown, typically
(most easily) by having the main thread pthread_join() all the
'children' (in quotes because no hierarchy is enforced).

- David.Thompson1 at worldnet.att.net

Re: terminate applications

[Robert I. Eachus]

Marin David Condic wrote:

> If Ada wants to be competitive against C, C++, Java or whatever else is 
> out there, it has to be focused on customer needs. It can't be dependent 
> on sending the customer to the competitor for features it can't or won't 
> support, or the customer just starts to wonder why he is bothering with 
> Ada when he has to have the other product anyway in order to get the job 
> done. Ada needs to provide "One-Stop Shopping" so a developer doesn't 
> need to look elsewhere for an answer.

As I have said, I think that you may have a need that should be 
addressed.  But remember what you are asking for here.  To get to the 
point where you need this feature in Ada, you have to use not normal 
(Ada 83) tasking but protected objects or asynchronous transfer of 
control.  Furthermore you have to place a blocking action--or more 
normally an endless loop--inside an abort deferred region.

As I said, I certainly agree that, especially for debugging situations, 
such a feature would be nice to have.  But the more I think about it, 
the more I think that the right solution may be to add a special 
procedure that breaks the abort deferral.  Let's see,

with Ada.Task_Identification; use Ada.Task_Identification;
procedure Exit_Abort_Deferred_Region is
begin
   if Is_Terminated(Current_Task) then raise Program_Error; end if;
end Exit_Abort_Deferred_Region;

Not very special after all, but you do need Ada.Task_Identification from 
Annex C.  And if you do insist on putting loops inside protected object, 
probably a useful tool to have around.  (For example, if you do a search 
through a linked list. Or use an AVL or other type of tree and do 
lookups.)  Putting that in busy waits inside protected objects and in 
other loops where you might have a problem solves part of the problem.

The other problem, of aborting a task that is waiting IN the OS has to 
be an implementation defined thing.  But it shouldn't be too hard to 
talk your vendor in to checking whether a task that is being aborted is 
waiting in an OS call and doing whatever OS specific thing is required 
to get out there.  Especially where Ada tasks correspond to OS threads, 
that shouldn't be too hard.  You don't care why that (abort protected) 
thread is not in a ready state in the OS, you want to kill any such 
threads.  (Since making a blocking call from an abort protected region 
is a bounded error, I don't think any langauge changes are required for 
this.)

-- 

                                                Robert I. Eachus

�In an ally, considerations of house, clan, planet, race are 
insignificant beside two prime questions, which are: 1. Can he shoot? 2. 
Will he aim at your enemy?� -- from the Laiden novels by Sharon Lee and 
Steve Miller.

Re: terminate applications

[Marin David Condic]

I'll grant you, it isn't as if it is a huge amount of work to import it 
from the standard C library. But that presumes you *have* the standard C 
library, doesn't it? It means you have to have C. If I have to keep 
resorting to C to get this or that capability, why not just do the job 
in C? Every time Ada says "Go call the C library..." it is telling the C 
programmers "You're right. You can't do the job in Ada. You have to use 
C." That's not very good advertising.

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?

As for the fact that C can modify a for loop variable and Ada can't, I 
find that not to be a compelling analogy. In Ada, if I needed that 
feature, I'd declare another variable and keep incrementing that counter 
& modify it as I needed to. The facility exists *entirely within Ada* 
and doesn't require that I embed some non-standard, external operation 
into my code that may or may not work if I want to take it to another 
environment.

If Ada had *everything* that C had (like an operating system, a 
database, a GUI, a network, etc.,) then people might find it a more 
attractive environment in which to program. Since we can't get there all 
in one giant leap, I think we at least ought to start with the things 
that *are* achievable in some reasonable span of time - like getting a 
"HALT" subprogram (and other related OS connections) into some sort of 
standard library.

MDC



Samuel Tardieu wrote:
> 
> I don't get your point: importing exit() from the standard C library
> is not more difficult than instantiating Ada.Unchecked_Dellocation to
> reclaim unused memory space. If the programmer really needs this
> feature badly, it only takes a few characters to use it.
> 
> C, and many other languages, do have the ability of modifying a loop
> index within the loop. We do not have this in the Ada "for" loop", but we
> can "emulate" this with a varianle and a simple or a "while" loop. The
> situation is similar here. If you want to do it, you can, but there is
> no need to make it a language construct or a standard library.
> 
>   Sam


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jast.mil/

Send Replies To: m c o n d i c @ a c m . o r g

     "In general the art of government consists in taking as
     much money as possible from one class of citizens to give
     to the other."

         --  Voltaire
======================================================================

Re: terminate applications

[Marin David Condic]

I think the answer is to have a standard library of stuff that provides 
connections to common OS operations. Most OS's support some kind of 
process kill capability - we just need a standard interface to it. In 
"normal" conditions, you use the Ada task abortion. When you need some 
specialized OS capability (such as killing without concern for cleanup, 
etc.) you connect to the OS in a standard way and let it do the wet-work 
for you.

C saw a need to connect to the OS - it *is* the OS in many cases - so it 
has lots of nice, convenient, reasonably portable hooks for doing OS 
operations. Ada could do the same. Problem solved. :-)

MDC


Robert I. Eachus wrote:
> 
> The other problem, of aborting a task that is waiting IN the OS has to 
> be an implementation defined thing.  But it shouldn't be too hard to 
> talk your vendor in to checking whether a task that is being aborted is 
> waiting in an OS call and doing whatever OS specific thing is required 
> to get out there.  Especially where Ada tasks correspond to OS threads, 
> that shouldn't be too hard.  You don't care why that (abort protected) 
> thread is not in a ready state in the OS, you want to kill any such 
> threads.  (Since making a blocking call from an abort protected region 
> is a bounded error, I don't think any langauge changes are required for 
> this.)
> 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jast.mil/

Send Replies To: m c o n d i c @ a c m . o r g

     "In general the art of government consists in taking as
     much money as possible from one class of citizens to give
     to the other."

         --  Voltaire
======================================================================

Re: terminate applications

[Randy Brukardt]

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

Re: terminate applications

[Hyman Rosen]

Randy Brukardt wrote:
> Finalization is the key to building maintainable abstractions, and we simply
> cannot allow cases in which that finalization does not happen.

But that's not really under your control. In Windows or UNIX, there are
ways to immediately kill a program from the outside, regardless of what
the program would prefer. And these services are available to a program
that wishes to invoke them, even on itself. So you don't gain anything
by making believe that such a thing does not exist, and you get in the
way of the programmer who has a perfectly good reason for wanting to do
it.

Re: terminate applications

[tmoran]

> But that's not really under your control. In Windows or UNIX, there are
> ways to immediately kill a program from the outside, regardless of what
> the program would prefer. And these services are available to a program
> that wishes to invoke them, even on itself. So you don't gain anything
  Of course you do.  You make it less convenient for the fast acting,
slow thinking, programmer to shoot himself in the foot, at the cost of
minor inconvenience on those less common occasions when system abort is
actually necessary.
  It must be a curious world, where all editors allow arbitrary length
lines, rocket controls once made either plug in and work in all future
kinds of space transport or specify in advance which ones won't work, and
there's no difference between leading into or leading away from temptation.

Re: terminate applications

[Hyman Rosen]

tmoran@acm.org wrote:
>   Of course you do.  You make it less convenient for the fast acting,
> slow thinking, programmer to shoot himself in the foot, at the cost of
> minor inconvenience on those less common occasions when system abort is
> actually necessary.

I have an idea! Every once in a while, Ada programming environments should
randomly change a character somewhere in a source file. This will force the
programmer to reread all the code looking for the error, making him become
more acquainted with the program, and allowing hin to serendipitously find
lurking bugs.

Re: terminate applications

[Dmitry A. Kazakov]

On Thu, 24 Jul 2003 01:47:36 GMT, Hyman Rosen <hyrosen@mail.com>
wrote:

>Randy Brukardt wrote:
>> Finalization is the key to building maintainable abstractions, and we simply
>> cannot allow cases in which that finalization does not happen.
>
>But that's not really under your control. In Windows or UNIX, there are
>ways to immediately kill a program from the outside, regardless of what
>the program would prefer.

[Yes, that small button, called "Reset" on the front panel!]

If you don't believe Randy, then here is a quote from MSDN regarding
TerminateProcess:

[QUOTE START]
... The TerminateProcess function is used to unconditionally cause a
process to exit. Use it only in extreme circumstances. The state of
global data maintained by dynamic-link libraries (DLLs) may be
compromised if TerminateProcess is used rather than ExitProcess.
...
DLLs attached to the process are not notified that the process is
terminating.

Terminating a process does not generate notifications for WH_CBT hook
procedures.
[QUOTE END]

Read the above carefully, and you will understand, why one should
never ever do such a thing under Windows.

> And these services are available to a program
>that wishes to invoke them, even on itself. So you don't gain anything
>by making believe that such a thing does not exist, and you get in the
>way of the programmer who has a perfectly good reason for wanting to do
>it.

Probably the programmer has not done his homework. In a properly
designed system there is no need in things like that. Even less Ada
standard should encourage them.

---
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de

Re: terminate applications

[Samuel Tardieu]

>>>>> "Hyman" == Hyman Rosen <hyrosen@mail.com> writes:

Hyman> I have an idea! Every once in a while, Ada programming
Hyman> environments should randomly change a character somewhere in a
Hyman> source file. This will force the programmer to reread all the
Hyman> code looking for the error, making him become more acquainted
Hyman> with the program, and allowing hin to serendipitously find
Hyman> lurking bugs.

This has nothing to do with Ada, but with programming techniques in
general, and I agree with you.

I for example like to reread the code I write a few days later. I
usually end up by adding some more comments (anything which does not
look trivial or which raises the question "why didn't I do that
another way?" causes the answer to be written in comments), and
sometimes by renaming some entities or by rewriting some algorithms.

Rereading one's own code improves it and makes future maintenance much
easier.

  Sam
-- 
Samuel Tardieu -- sam@rfc1149.net -- http://www.rfc1149.net/sam

Re: terminate applications

[Marin David Condic]

You mean like when the end user types control-C? Or lightning takes out 
the junction box in your neighborhood and the power goes down? Or, 
because you're on Windows the OS decides to take an arbitrary dirt nap 
for no apparent reason?

If most OS's provide a given feature, there ought to be a way for an Ada 
program to utilize that feature in a standard way. Worrying about the 
fact that some OS provided feature might not fit in with Ada's desired 
safety and security is what is going to guarantee that programmers are 
going to do end-runs around Ada to use the C/C++ library that *will* 
give them the feature - and eventually decide that its too much of a 
nuisance to be programming in both Ada and C and revert to C.

My arguement here is that programmers are going to want and/or need 
features that come from the operating system - halting a program in 
mid-breath is just one of them. Not all of those OS features are going 
to be nice, clean, perfectly safe Ada-ish operations, but so what? You 
include the caveats "Implementation defined" and "Use at your own risk". 
You either provide the OS operations in some semi-standard, 
semi-portable way or the programmer does the end-run around you, or the 
programmer simply abandons Ada. I'd say the first option was the better 
one for the futrue of Ada.

MDC



Randy Brukardt wrote:
> 
> 
> 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.
> 

-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jast.mil/

Send Replies To: m c o n d i c @ a c m . o r g

     "In general the art of government consists in taking as
     much money as possible from one class of citizens to give
     to the other."

         --  Voltaire
======================================================================

Re: terminate applications

[Marin David Condic]

That's the point. You won't stop programmers from doing it - only get in 
their way and convince them that Ada is too inconvenient for "real" 
work. Notice that when I first mentioned this issue, there were any 
number of posts saying "Well, all you have to do is bind to this C 
routine that will do it for you..." - so the suggestion seems to 
indicate that if you're going to do something "dirty" you should make 
some other language do it so Ada doesn't soil her hands. :-)

OS's provide features and Ada ought to provide a standard - or at least 
a "conventional" - way of getting at them so that code developed in one 
system stands a chance of being portable to another. Maybe it doesn't 
belong in the Ada Reference Manual, but I have long lobbied for the 
notion of a conventional library outside of the standard for just this 
sort of thing. Wherever it ends up, so long as it is portable across 
most vendors & platforms, it would be a good thing.

MDC

Hyman Rosen wrote:
> 
> But that's not really under your control. In Windows or UNIX, there are
> ways to immediately kill a program from the outside, regardless of what
> the program would prefer. And these services are available to a program
> that wishes to invoke them, even on itself. So you don't gain anything
> by making believe that such a thing does not exist, and you get in the
> way of the programmer who has a perfectly good reason for wanting to do
> it.
> 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jast.mil/

Send Replies To: m c o n d i c @ a c m . o r g

     "In general the art of government consists in taking as
     much money as possible from one class of citizens to give
     to the other."

         --  Voltaire
======================================================================

Re: terminate applications

[Warren W. Gay VE3WWG]

"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

Re: terminate applications

[Warren W. Gay VE3WWG]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message news:ek2vhv4qcbtj4hspi2c0lojbtsh1baldql@4ax.com...
> On Thu, 24 Jul 2003 01:47:36 GMT, Hyman Rosen <hyrosen@mail.com>
> wrote:
>
> >Randy Brukardt wrote:
> >> Finalization is the key to building maintainable abstractions, and we simply
> >> cannot allow cases in which that finalization does not happen.
> >
> >But that's not really under your control. In Windows or UNIX, there are
> >ways to immediately kill a program from the outside, regardless of what
> >the program would prefer.
>
> [Yes, that small button, called "Reset" on the front panel!]
>
> If you don't believe Randy, then here is a quote from MSDN regarding
> TerminateProcess:
>
> [QUOTE START]
> ... The TerminateProcess function is used to unconditionally cause a
> process to exit. Use it only in extreme circumstances. The state of
> global data maintained by dynamic-link libraries (DLLs) may be
> compromised if TerminateProcess is used rather than ExitProcess.
> ...
> DLLs attached to the process are not notified that the process is
> terminating.
>
> Terminating a process does not generate notifications for WH_CBT hook
> procedures.
> [QUOTE END]
>
> Read the above carefully, and you will understand, why one should
> never ever do such a thing under Windows.

And COM objects, where they do reference counting. Personally, I think
a lot of this crap is due to bad design within Windows. Not that UNIX
fully escapes these issues, but there seems to be fewer of these issues
under UNIX.

Unfortunately, there are still issues which require you to take some
drastic action. Not everyone is prepared to wait until the next power
failure for a hung process ;-)


>> And these services are available to a program
> >that wishes to invoke them, even on itself. So you don't gain anything
> >by making believe that such a thing does not exist, and you get in the
> >way of the programmer who has a perfectly good reason for wanting to do
> >it.
>
> Probably the programmer has not done his homework. In a properly
> designed system there is no need in things like that. Even less Ada
> standard should encourage them.

Perhaps, and perhaps not because it is due to an O/S bug where it
blocks on an O/S call when it should return an error. Things are not
always so cut and dry.

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

Re: terminate applications

[Dmitry A. Kazakov]

On Thu, 24 Jul 2003 10:54:51 -0400, "Warren W. Gay VE3WWG"
<ve3wwg@cogeco.ca> wrote:

>"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message news:ek2vhv4qcbtj4hspi2c0lojbtsh1baldql@4ax.com...
>> On Thu, 24 Jul 2003 01:47:36 GMT, Hyman Rosen <hyrosen@mail.com>
>> wrote:
>> Probably the programmer has not done his homework. In a properly
>> designed system there is no need in things like that. Even less Ada
>> standard should encourage them.
>
>Perhaps, and perhaps not because it is due to an O/S bug where it
>blocks on an O/S call when it should return an error. Things are not
>always so cut and dry.

The point is why your code should behave as Windows does? An Ada
application can be and should be designed in a way allowing a graceful
exit provided that underlying OS is OK.

It means that the single reason why it might hang up is a call to some
buggy OS API. If so, then you can well use another buggy API call to
terminate it.

Now, how this can support any need to incorporate that buggy API into
the standard?

Let operation F yelds an unpredictable result. Why one would like to
call F? It would make WHAT?

Isn't is Ariane 5 syndrome: (:-))

exception
   when Project_Mismanagement  =>

---
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de

Re: terminate applications

[Robert I. Eachus]

Marin David Condic wrote:
> I think the answer is to have a standard library of stuff that provides 
> connections to common OS operations. Most OS's support some kind of 
> process kill capability - we just need a standard interface to it. In 
> "normal" conditions, you use the Ada task abortion. When you need some 
> specialized OS capability (such as killing without concern for cleanup, 
> etc.) you connect to the OS in a standard way and let it do the wet-work 
> for you.

First you ignored this code snippet for putting in any loops in an abort 
deferred region.  You should probably wrap OS calls in an abort deferred 
region with a tendancy to hang in an ATC with similar effects. Of 
course, better is not to put OS calls in protected objects, but 
sometimes, as in device drivers or interrupt handlers, it is necessary.

with Ada.Task_Identification; use Ada.Task_Identification;
procedure Exit_Abort_Deferred_Region is
begin
   if Is_Terminated(Current_Task) then raise Program_Error; end if;
end Exit_Abort_Deferred_Region;

Having said that, in one sense this argument is specious.  In Ada 83, 
abort meant "terminate with extreme predjudice."  Ada 83 code compiled 
with an Ada 95 compiler will have the same semantics--Ada 95 abort can 
only hang in the presense of Ada 95 extensions to Ada 83.

The argument that you couldn't abort the environment task in Ada 83 is 
also specious.  Ada 83 did not forbid it, but also did not provide a 
non-implementation specific name for the environment task.  However, the 
main program, or anything running in the main task could execute an 
abort with no argument, which aborted the environment task and all 
dependent tasks.

So the question should not be, "Is this feature in good taste?" but "Is 
this feature needed in the presence of the new Ada 95 extensions.  There 
are good arguments on both sides, but I tend to feel that such a 
super-abort or �berkill is necessary and should be provided in Annex D. 
  And as I also said, the procedure should do as much cleanup as 
possible, subject to a time limit, something like:

procedure Abort_All(Timeout: Duration);

So that Abort_All(3.0) allows for reasonable last wishes, and 
Abort_All(0.0) says kill everything now.  The reference manual can say 
that the Timeout value should be chosen to allow all non-abort deferred 
tasks to complete their cleanup.

-- 

                                                        Robert I. Eachus

�In an ally, considerations of house, clan, planet, race are 
insignificant beside two prime questions, which are: 1. Can he shoot? 2. 
Will he aim at your enemy?� -- from the Laiden novels by Sharon Lee and 
Steve Miller.

Re: terminate applications

[tmoran]

>To solve MDC's problem, and all that is needed is a sufficiently rounded
>GPLed Halt package, that applies to popular platforms.
  May I offer:
procedure Suicide;
-- Implementation defined action.  Generally, calls the OS requesting
-- immediate termination of the partition, usually without any cleanup
-- or finalization.  On many OSes, this may need to be followed by
-- a manual reboot.  Using a vendor supplied Halt, or aborting the
-- environment task, will usually acomplish more graceful termination.
The body of Suicide needs to be written specificaly for each OS.

Re: terminate applications

[Randy Brukardt]

"Hyman Rosen" <hyrosen@mail.com> wrote in message
news:8CITa.22321$0F4.22242@nwrdny02.gnilink.net...
> I have an idea! Every once in a while, Ada programming environments should
> randomly change a character somewhere in a source file. This will force
the
> programmer to reread all the code looking for the error, making him become
> more acquainted with the program, and allowing hin to serendipitously find
> lurking bugs.

Very early PCs that we worked on tended to do that periodically. But it
wasn't very effective on forcing re-reading of Ada code, because most single
character changes cause a compile-time error (or are in comments, where they
don't matter anyway).

But the general sentiment is correct: re-reading old code often finds bugs.
That happens nearly every time I go into our compiler looking for a bug; I
often end up fixing three of four bugs before I finally find the one I was
originally looking for.

                    Randy.

Re: terminate applications

[Randy Brukardt]

"Hyman Rosen" <hyrosen@mail.com> wrote in message
news:YUGTa.22178$0F4.4025@nwrdny02.gnilink.net...
> Randy Brukardt wrote:
> > Finalization is the key to building maintainable abstractions, and we
simply
> > cannot allow cases in which that finalization does not happen.
>
> But that's not really under your control. In Windows or UNIX, there are
> ways to immediately kill a program from the outside, regardless of what
> the program would prefer.

Of course, the "outside force" killing cannot be avoided. But users
hopefully know that doing such things is dangerous. Windows pops up a
warning whenever you try to kill a process from the GUI, for instance.

> And these services are available to a program
> that wishes to invoke them, even on itself. So you don't gain anything
> by making believe that such a thing does not exist, and you get in the
> way of the programmer who has a perfectly good reason for wanting to do
> it.

Ah, but we're talking about what goes into the language standard, not what a
programmer might do in some circumstance.

Moreover, I do not believe that there are many (if any at all) "perfectly
good reasons" for unsafely killing yourself. (The standard cannot talk about
killing other partitions; everything about running partitions is
implementation-defined.) You need to do it if the program is hung, of
course, but in that case it is clear that an outside force has to do it. If
the program is not hung, there is little value to not doing it safely.
Presuming Finalize routines are written to be fault-tolerant (which they
have to be for reasons having nothing to do with program exiting), there is
no problem with exiting the program with the finalization. If the
finalization takes a long time, then there is something seriously wrong with
the program design, and that should be addresses, not some suicide package.

This need, if it really exists at all, is so rare that I see no reason for
it to be included in the standard. OTOH, I would not object to a safe Halt
routine (which was defined to be the same as aborting the environment task)
which would be (A) well-defined; (B) wouldn't leave critical resources in an
undefined state; and (C) be more convinient, especially if you are in some
other task. (To abort the environment task requires planning ahead, and it
would be of value to avoid that). That would be enough in 99% of the cases,
and moreover, the presence of such a routine would prod vendors to insure
that aborting the environment task actually works.

An Unconditional_Exit routine would have to essentially say "Causes the
program to end as soon as possible. It is unspecified whether any
finalization is done before the program exits and how any tasks are
terminated." And then it would have to be followed with a note suggesting
that it be used with extreme caution. I don't see the point.

                                Randy.

Re: terminate applications

[Randy Brukardt]

"Marin David Condic" <nobody@noplace.com> wrote in message
news:3F1FC849.8070202@noplace.com...
> If most OS's provide a given feature, there ought to be a way for an Ada
> program to utilize that feature in a standard way. Worrying about the
> fact that some OS provided feature might not fit in with Ada's desired
> safety and security is what is going to guarantee that programmers are
> going to do end-runs around Ada to use the C/C++ library that *will*
> give them the feature - and eventually decide that its too much of a
> nuisance to be programming in both Ada and C and revert to C.

I agree that common operations from the OS ought to be supported in a
standard way. But I disagree that that includes dangerous operations.

Don't you think that if the standard Ada library provided a safe Halt
routine, people would use that, and 98% of the time, it would be perfectly
adaquate? I cannot remember a case (either from us or from our users) where
someone said that System.Util.Halt was too slow or hung.

Similarly, if Ada provided "safe" libraries of OS operations, don't you
think people would use them? Do you really think that people would say that
such-and-such an operation is safe, so I won't use it?

Why should we go on propagating the mistakes of our forefathers? The
functionality is the important point, not the exact form or details. If you
don't believe that - if you believe that Ada can't be object-oriented
because it doesn't declare "class"es, for instance - then you SHOULD be
using C++. Ada has nothing to offer you then.

We should stick with "safe", well-defined operations in the standard Ada
library. After all, people will use those first. If they absolutely have to
use an unsafe operation, fine, but they'll have to do it by a direct
interface to the OS (making the OS dependence clear).

(For what's its worth, the C Exit is a safe exit -- for C. It does lots of
finalization activities before it actually exits. Why should Ada be
different in that regard?)

                              Randy.

Re: terminate applications

[Robert I. Eachus]

Randy Brukardt wrote:

> Moreover, I do not believe that there are many (if any at all) "perfectly
> good reasons" for unsafely killing yourself. 

Taken out of context, I certainly have to agree.  If you are going to 
kill yourself you should do it as safely as possible. ;-)

But back to the matter under discussion, I have worked on programs where 
a great deal of effort was "wasted" proving that a task could be killed 
within X milliseconds.  The advantage to defining the type of two-stage 
kill I recommend is that it allows time for "last wishes," and for 
things that can terminate cleanly to do so.  But when you hit the time 
limit, then you get the brute force.

-- 

                                                        Robert I. Eachus

�In an ally, considerations of house, clan, planet, race are 
insignificant beside two prime questions, which are: 1. Can he shoot? 2. 
Will he aim at your enemy?� -- from the Laiden novels by Sharon Lee and 
Steve Miller.

Re: terminate applications

[Warren W. Gay VE3WWG]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message news:bluvhvsr5kagtd9ksjdlpasf2iamcgu67v@4ax.com...
> On Thu, 24 Jul 2003 10:54:51 -0400, "Warren W. Gay VE3WWG"
> <ve3wwg@cogeco.ca> wrote:
>
> >"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message news:ek2vhv4qcbtj4hspi2c0lojbtsh1baldql@4ax.com...
> >> On Thu, 24 Jul 2003 01:47:36 GMT, Hyman Rosen <hyrosen@mail.com>
> >> wrote:
> >> Probably the programmer has not done his homework. In a properly
> >> designed system there is no need in things like that. Even less Ada
> >> standard should encourage them.
> >
> >Perhaps, and perhaps not because it is due to an O/S bug where it
> >blocks on an O/S call when it should return an error. Things are not
> >always so cut and dry.
>
> The point is why your code should behave as Windows does? An Ada
> application can be and should be designed in a way allowing a graceful
> exit provided that underlying OS is OK.

I am not disputing that good design should be used, and I doubt
the OP was either. However, there are practical situations outside
of rockets and weapons where a "kill -9" feature is useful (debugging
has already been suggested as one good one).

> Now, how this can support any need to incorporate that buggy API into
> the standard?

You are labelling it a "buggy API". I see this as a legitamate
function. For example, if an some internal assertion fails, it may
be highly desireable to have the whole application be "canned"
immediately, without a shutdown (which might inflict further damage).

The problem as I see it, is that there is a very strong tension between
the embedded/rocket/life-threatening developers and those that write
much more mundane applications. I feel this same tension is rearing
its head here. If Ada is to gain wider exceptance, you need to take
those blinkers off. ;-)

The embedded people don't want it because they don't want it used (to
that I say fine, don't use it!)  Ravenscar avoids a large portion
of Ada features that it considers "unsafe". What harm can one more
"feature" bring if it is correctly documented?

To use an analogy you want to ban emergency brakes because they're
weak, and almost useless. Yet every car in North America must have
one.  I think having the choice of an emergency brake makes sense.
No one is suggesting that you should use it, or that it be recommended.
It merely should exist to offer a choice for those practical
situations where it might be useful and valid.

> Let operation F yelds an unpredictable result. Why one would like to
> call F? It would make WHAT?

Keep in mind that many API calls are made underneath the hood, and
by libraries. The programmer is not always directly involved in
the problem.

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

Re: terminate applications

[Warren W. Gay VE3WWG]

"Randy Brukardt" <randy@rrsoftware.com> wrote in message news:vi0gf8rnbu9b09@corp.supernews.com...
> "Marin David Condic" <nobody@noplace.com> wrote in message
> news:3F1FC849.8070202@noplace.com...
> > If most OS's provide a given feature, there ought to be a way for an Ada
> > program to utilize that feature in a standard way. Worrying about the
> > fact that some OS provided feature might not fit in with Ada's desired
> > safety and security is what is going to guarantee that programmers are
> > going to do end-runs around Ada to use the C/C++ library that *will*
> > give them the feature - and eventually decide that its too much of a
> > nuisance to be programming in both Ada and C and revert to C.
>
> I agree that common operations from the OS ought to be supported in a
> standard way. But I disagree that that includes dangerous operations.

But dangerous for whom?  RAVENSCAR defines a number of Ada
features that they consider "unsafe", yet these features are
not soon to be removed from the "standard".

You must look at the application first. The OP has an "application"
for this feature, and I think it is presumptuous for us to say
that it is too dangerous to be used.

...
> Why should we go on propagating the mistakes of our forefathers? The
> functionality is the important point, not the exact form or details. If you
> don't believe that - if you believe that Ada can't be object-oriented
> because it doesn't declare "class"es, for instance - then you SHOULD be
> using C++. Ada has nothing to offer you then.

Let me ask a hypothetical question: which car would you prefer?

  1. Your year 2030 minivan says to you "I will not start because the
     hatch sensor indicates that it is not fully closed."  "Please
     correct the problem or get it repaired and try again. Have
     a nice day!"

or

  2. Your year 2030 minivan says "I will not start because the hatch
     sensor indicates that it is not fully closed. If you have
     checked the hatch, and it appears OK, then enter code XYZZY
     and then I will proceed anyway."

Which would you choose?  Microsoft will offer the #1 firmware.


For me, it better be #2, because I want to be in control! Not the
so and so manufacturer!

I think this API feature is about control. It has many times been
conceded that this is not the correct thing to do. But there are
_practical_ needs for this, if not for anything else, but for
testing.

> We should stick with "safe", well-defined operations in the standard Ada
> library. After all, people will use those first. If they absolutely have to
> use an unsafe operation, fine, but they'll have to do it by a direct
> interface to the OS (making the OS dependence clear).
>
> (For what's its worth, the C Exit is a safe exit -- for C. It does lots of
> finalization activities before it actually exits. Why should Ada be
> different in that regard?)
>
>                               Randy.

Ah, but exit() is only one C choice. The function _exit() is _also_
callable by the C programmer. Again, it is acknowledged that there
are good reasons not to use this, but the C programmer DOES have
the CHOICE to do so when it is required.

Give the programmer a choice. Document it as dangerous or
unsupported, but give the programmer the choice. Management can
dictate it out of a project if it needs to.

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

Re: terminate applications

[Warren W. Gay VE3WWG]

"Randy Brukardt" <randy@rrsoftware.com> wrote in message news:vi0favi91fib92@corp.supernews.com...
> "Hyman Rosen" <hyrosen@mail.com> wrote in message
> news:YUGTa.22178$0F4.4025@nwrdny02.gnilink.net...
> > Randy Brukardt wrote:
> > > Finalization is the key to building maintainable abstractions, and we
> simply
> > > cannot allow cases in which that finalization does not happen.
> >
> > But that's not really under your control. In Windows or UNIX, there are
> > ways to immediately kill a program from the outside, regardless of what
> > the program would prefer.
>
> Of course, the "outside force" killing cannot be avoided. But users
> hopefully know that doing such things is dangerous. Windows pops up a
> warning whenever you try to kill a process from the GUI, for instance.

The warning is almost useless. It only offers the user a chance
to cancel the request. It does not educate a user about whether
it is safe or not (it cannot know), and unless you already have
inside developer knowledge of the application, you won't know
either.  Any grandmother will not know which answer to choose
for example. So if grannies learn to use the task manager, they
will just go ahead and do it if that is what they want! Or more
likely, they'll shy away from dangerous talk and end up rebooting
because the problem will remain unsolved (which, in the end
amounts to almost the same thing as far as the tasks are concerned).

So the practical matter is "Houston, we have a problem." The application
is hung, so now you have lost control of it. The O/S is no help if you
say that killing the processes shouldn't be done. But wait, rebooting
amounts to the same thing... "so Houston, we are waiting for your answer
from engineering? What are we to do, sitting in our tin can?"   ;-)

> An Unconditional_Exit routine would have to essentially say "Causes the
> program to end as soon as possible. It is unspecified whether any
> finalization is done before the program exits and how any tasks are
> terminated." And then it would have to be followed with a note suggesting
> that it be used with extreme caution. I don't see the point.
>
>                                 Randy.

OK, take the _exit() function away from C programmers and listen to the
clamor then! You would be an unpopular fellow ;-)

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

Re: terminate applications

[Marin David Condic]

O.K., but what is wrong with saying that most operating systems provide 
some means of immediate process termination in the form of a system call 
and that Ada ought to have a portable and common binding to that (and 
other) OS procedures? OS's provide services. Programmers want to use 
those services. Ada seems to be insisting "No, I won't let you use this 
one because it isn't safe, but if you want to do it behind my back, call 
this C function when I'm not looking..."

Every so often, I like to run with scissors just because I'm a grownup 
and can do it now without getting yelled at. :-)

MDC

Robert I. Eachus wrote:
> 
> But back to the matter under discussion, I have worked on programs where 
> a great deal of effort was "wasted" proving that a task could be killed 
> within X milliseconds.  The advantage to defining the type of two-stage 
> kill I recommend is that it allows time for "last wishes," and for 
> things that can terminate cleanly to do so.  But when you hit the time 
> limit, then you get the brute force.
> 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jast.mil/

Send Replies To: m c o n d i c @ a c m . o r g

     "In general the art of government consists in taking as
     much money as possible from one class of citizens to give
     to the other."

         --  Voltaire
======================================================================

Re: terminate applications

[Marin David Condic]

Because Ada can't guarantee that at all times and under all conditions 
it can shoot the process in the head (apparently). If you have tasks 
that are hung up in some OS operation and you want to kill the process 
as a result, you probably have to rely on the OS. And then you have to 
live with the weaknesses of the OS - which you already had to do because 
you were making OS calls. What is wrong with making OS calls? Yes, it 
isn't perfectly safe. No I won't stop doing it. Please give me a common, 
conventional, portable interface to the OS so I can do the dangerous 
things I want to do and then port my dangerous code to another OS or 
compiler with relative ease. :-)

If Ada can find a way of saying "Here's a safe, reliable HALT subprogram 
that is 100% guaranteed to kill the program no matter what" I say 
"Fine". However, I suspect that the only way to get the 100% guarantee 
part is to hook to the OS that may be hanging up a task. Hence you lose 
some safety. That's fine with me. I promise I'll only use it in extreme 
cases.

MDC

Randy Brukardt wrote:
> "Marin David Condic" <nobody@noplace.com> wrote in message
> news:3F1FC849.8070202@noplace.com...
> 
>>If most OS's provide a given feature, there ought to be a way for an Ada
>>program to utilize that feature in a standard way. Worrying about the
>>fact that some OS provided feature might not fit in with Ada's desired
>>safety and security is what is going to guarantee that programmers are
>>going to do end-runs around Ada to use the C/C++ library that *will*
>>give them the feature - and eventually decide that its too much of a
>>nuisance to be programming in both Ada and C and revert to C.
> 
> 
> I agree that common operations from the OS ought to be supported in a
> standard way. But I disagree that that includes dangerous operations.
> 
> Don't you think that if the standard Ada library provided a safe Halt
> routine, people would use that, and 98% of the time, it would be perfectly
> adaquate? I cannot remember a case (either from us or from our users) where
> someone said that System.Util.Halt was too slow or hung.
> 
> Similarly, if Ada provided "safe" libraries of OS operations, don't you
> think people would use them? Do you really think that people would say that
> such-and-such an operation is safe, so I won't use it?
> 
> Why should we go on propagating the mistakes of our forefathers? The
> functionality is the important point, not the exact form or details. If you
> don't believe that - if you believe that Ada can't be object-oriented
> because it doesn't declare "class"es, for instance - then you SHOULD be
> using C++. Ada has nothing to offer you then.
> 
> We should stick with "safe", well-defined operations in the standard Ada
> library. After all, people will use those first. If they absolutely have to
> use an unsafe operation, fine, but they'll have to do it by a direct
> interface to the OS (making the OS dependence clear).
> 
> (For what's its worth, the C Exit is a safe exit -- for C. It does lots of
> finalization activities before it actually exits. Why should Ada be
> different in that regard?)
> 
>                               Randy.
> 
> 
> 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jast.mil/

Send Replies To: m c o n d i c @ a c m . o r g

     "In general the art of government consists in taking as
     much money as possible from one class of citizens to give
     to the other."

         --  Voltaire
======================================================================

Re: terminate applications

[Marin David Condic]

The critical point being that if you *don't* give the programmer the 
choice, he'll just do an end-run around you anyway and resent the fact 
that he has to go outside the language to get what he wants.

It's an OS operation and the programmer ought to be able to access the 
OS in a portable way - to whatever extent that is possible. It doesn't 
have to be part of the Ada standard if the Ada community can agree on 
building a conventional library that will be included in most/all compilers.

MDC


Warren W. Gay VE3WWG wrote:
> 
> Give the programmer a choice. Document it as dangerous or
> unsupported, but give the programmer the choice. Management can
> dictate it out of a project if it needs to.
> 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jast.mil/

Send Replies To: m c o n d i c @ a c m . o r g

     "In general the art of government consists in taking as
     much money as possible from one class of citizens to give
     to the other."

         --  Voltaire
======================================================================

Re: terminate applications

[Marin David Condic]

O.K. I'm probably smart enough to generate my own package to do it. I 
could probably generate my own binding to the C routines necessary to 
make it happen. My concern is that it ought to be done in a way that is 
*standard* across compilers and platforms - to the extent that is 
possible. Having it in some conventional library that is supplied by 
most vendors would solve that problem.

MDC

tmoran@acm.org wrote:
>>To solve MDC's problem, and all that is needed is a sufficiently rounded
>>GPLed Halt package, that applies to popular platforms.
> 
>   May I offer:
> procedure Suicide;
> -- Implementation defined action.  Generally, calls the OS requesting
> -- immediate termination of the partition, usually without any cleanup
> -- or finalization.  On many OSes, this may need to be followed by
> -- a manual reboot.  Using a vendor supplied Halt, or aborting the
> -- environment task, will usually acomplish more graceful termination.
> The body of Suicide needs to be written specificaly for each OS.


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jast.mil/

Send Replies To: m c o n d i c @ a c m . o r g

     "In general the art of government consists in taking as
     much money as possible from one class of citizens to give
     to the other."

         --  Voltaire
======================================================================

Re: terminate applications

[Larry Kilgallen]

In article <3F227982.30204@noplace.com>, Marin David Condic <nobody@noplace.com> writes:
> O.K., but what is wrong with saying that most operating systems provide 
> some means of immediate process termination in the form of a system call 
> and that Ada ought to have a portable and common binding to that (and 
> other) OS procedures?

What is wrong is that not all operating systems define those facilities
in the same way.  Ada programmers moving such code from one platform to
another should be forced to read the definition for the particular OS
to see if it still matches the expectations of their program.

VMS has about three such calls, with varying effects.  Which one should
an Ada compiler invoke ?

Re: terminate applications

[Warren W. Gay VE3WWG]

"Larry Kilgallen" <Kilgallen@SpamCop.net> wrote in message news:$TwrUBtoh25l@eisner.encompasserve.org...
> In article <3F227982.30204@noplace.com>, Marin David Condic <nobody@noplace.com> writes:
> > O.K., but what is wrong with saying that most operating systems provide
> > some means of immediate process termination in the form of a system call
> > and that Ada ought to have a portable and common binding to that (and
> > other) OS procedures?
>
> What is wrong is that not all operating systems define those facilities
> in the same way.  Ada programmers moving such code from one platform to
> another should be forced to read the definition for the particular OS
> to see if it still matches the expectations of their program.
>
> VMS has about three such calls, with varying effects.  Which one should
> an Ada compiler invoke ?

That is an interesting point. I don't know VMS, but I would expect
that the one that MDC is looking for can be chosen from that set.

How do these 3 vary?  Surely, one of these must be inline with what
other O/S's provide. The other API entries (if useful), can be provided
by a Halt.Aux package or some other extension perhaps.

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

Re: terminate applications

[Nick Roberts]

"Marin David Condic" <nobody@noplace.com> wrote in message
news:3F227F16.2010908@noplace.com...

> The critical point being that if you *don't* give the
> programmer the choice, he'll just do an end-run
> around you anyway and resent the fact that he has
> to go outside the language to get what he wants.

I think it might be valuable to add to the standard library a procedure,
perhaps:

   procedure Ada.Unsafe_Terminate_Program;

The RM could define the execution of this procedure maybe as follows:

----------

Dynamic Semantics

Unsafe_Terminate_Program causes the execution of all the tasks in all the
partitions of the program to immediately cease execution. No finalization
occurs, and execution within abort-deferred regions will be terminated
without any deferral. A call to Unsafe_Terminate_Program never returns. The
time or place at which each task ceases is undefined.

Implementation Requirements

Implementations must document all the potential consequences of the
execution of Unsafe_Terminate_Program which are different to those of normal
program termination.

Implementation Permissions

An implementation may omit Unsafe_Terminate_Program if it would be
unreasonable (or too dangerous) to provide it. The mechanisms used by an
implementation to cause the cessation of execution in tasks other than the
calling task (especially those in separate partitions) is undefined, thus
the speed at which this cessation is propagated, and whether it may or may
not succeed in being propagated to all tasks in a program, is undefined. An
implementation may perform some or all finalization, if it would be
unreasonable not to. An implementation may allow some or all executions
within abort-deferred regions to complete before cessation, if it would be
unreasonable to do otherwise.

Notes

It is intended that Unsafe_Program_Termination not only avoids any
finalization or completion of abort-deferred regions in any part of the Ada
program itself, but also that it avoids as much of the normal termination
actions associated with the execution environment as reasonably possible
(e.g. finalizations within a run-time environment). It is recommended that
Unsafe_Program_Termination is used only as a last resort, when all other
attempts at bringing a program to completion have failed. It is recommended
that Unsafe_Program_Termination is not used in deliverable software unless
its use is considered unavoidable. It is strongly recommended that whenever
a program which could possibly execute Unsafe_Program_Termination is
deployed in a different execution environment, or a change is made to that
environment, a thorough check is made as to the worst possible consequences
of its execution.

----------

I think this suggestion makes it clear that: the semantics of such a
procedure would be difficult to define, and impossible to enforce or test;
it truly could be really dangerous in some environments. You might consider
all the above a bit too much to add to the RM to be worth it.

--
Nick Roberts
Jabber: debater@charente.de [ICQ: 159718630]

Re: terminate applications

[Warren W. Gay VE3WWG]

"Nick Roberts" <nickroberts@blueyonder.co.uk> wrote in message news:bfu697$j1mk7$1@ID-25716.news.uni-berlin.de...
> "Marin David Condic" <nobody@noplace.com> wrote in message
> news:3F227F16.2010908@noplace.com...
>
> > The critical point being that if you *don't* give the
> > programmer the choice, he'll just do an end-run
> > around you anyway and resent the fact that he has
> > to go outside the language to get what he wants.
>
> I think it might be valuable to add to the standard library a procedure,
> perhaps:
>
>    procedure Ada.Unsafe_Terminate_Program;
>
> The RM could define the execution of this procedure maybe as follows:
>
> ----------
>
> Dynamic Semantics
>
> Unsafe_Terminate_Program causes the execution of all the tasks in all the
> partitions of the program to immediately cease execution. No finalization
> occurs, and execution within abort-deferred regions will be terminated
> without any deferral. A call to Unsafe_Terminate_Program never returns. The
> time or place at which each task ceases is undefined.

This looks good to me.

> Implementation Requirements
>
> Implementations must document all the potential consequences of the
> execution of Unsafe_Terminate_Program which are different to those of normal
> program termination.

I believe that this part may be too onerous, or at a minimum, should
be worded differently. I believe that the documentation should be
simply has you have described it under "Dynamic Semantics". Ie. that
everything stops, and there is no clean up or defined state left behind.

Expecting the compiler vendor to document the consequences is a
nightmare for them, IMHO.

If the idea of permitting this call scares people, then you could
make it illegal without the appropriate pragma or compiler option
switch.

> Implementation Permissions
>
> An implementation may omit Unsafe_Terminate_Program if it would be
> unreasonable (or too dangerous) to provide it.

The problem with this language is the word "dangerous". Who is going
to define what is dangerous for me? For someone writing code for
NASA or for flight controls, it would be. For me, it is not. I
move to strike "(or too dangerous)", since from a software purity
point of view, it probably is, most of the time.

> The mechanisms used by an
> implementation to cause the cessation of execution in tasks other than the
> calling task (especially those in separate partitions) is undefined, thus
> the speed at which this cessation is propagated, and whether it may or may
> not succeed in being propagated to all tasks in a program, is undefined.

Fine.

> An
> implementation may perform some or all finalization, if it would be
> unreasonable not to.

Again, who defines "unreasonable"? For me, I would say that finalization
is not desirable in this case (although perhaps this can be "optional"
giving the programmer more control).  Finalization is often the source
of hangs when things get beyond a "defined set of states", particularly
if devices are involved.

> An implementation may allow some or all executions
> within abort-deferred regions to complete before cessation, if it would be
> unreasonable to do otherwise.

I would say drop the "unreasonable" (it is not well defined) and simply
state that what gets completed or not is undefined (it is implementation
dependent).

> Notes
>
> It is intended that Unsafe_Program_Termination not only avoids any
> finalization

I think you are conflicting withyour self here ;-)

> or completion of abort-deferred regions in any part of the Ada
> program itself, but also that it avoids as much of the normal termination

The word "avoids as much of the normal" is not very well defined.

> actions associated with the execution environment as reasonably possible

The word "reasonable" again..

> (e.g. finalizations within a run-time environment). It is recommended that
> Unsafe_Program_Termination is used only as a last resort, when all other
> attempts at bringing a program to completion have failed.

I wouldn't make a recommendation here, but only state that it is "unsafe".

> It is recommended
> that Unsafe_Program_Termination is not used in deliverable software unless
> its use is considered unavoidable.

Again, I think "unsafe" is enough to state the case, and I would avoid
recommendations.

> It is strongly recommended that whenever
> a program which could possibly execute Unsafe_Program_Termination is
> deployed in a different execution environment, or a change is made to that
> environment, a thorough check is made as to the worst possible consequences
> of its execution.

As another recommendation, this is one that I don't think needs to be
made. "Unsafe" operations should not be used in areas where safety is
a concern. Where it is not a concern, then obviously the developer deserves
what he gets if he fails to take this obvious piece of advice to mind.

If you insist on putting something in this category of documentation, then
I would simply word something like "the behavior may VARY on different
environment platforms".

> I think this suggestion makes it clear that: the semantics of such a
> procedure would be difficult to define, and impossible to enforce or test;
> it truly could be really dangerous in some environments. You might consider
> all the above a bit too much to add to the RM to be worth it.

Overall, I think it is good, but I would eliminate the recommendations and
simply label it as "unsafe". For extra safety, you could make it illegal to
use without the appropriate use of a pragma or compile time option.

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

Re: terminate applications

[Larry Kilgallen]

In article <FTwUa.367$XK4.14917@read1.cgocable.net>, "Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> writes:
> "Larry Kilgallen" <Kilgallen@SpamCop.net> wrote in message news:$TwrUBtoh25l@eisner.encompasserve.org...
>> In article <3F227982.30204@noplace.com>, Marin David Condic <nobody@noplace.com> writes:
>> > O.K., but what is wrong with saying that most operating systems provide
>> > some means of immediate process termination in the form of a system call
>> > and that Ada ought to have a portable and common binding to that (and
>> > other) OS procedures?
>>
>> What is wrong is that not all operating systems define those facilities
>> in the same way.  Ada programmers moving such code from one platform to
>> another should be forced to read the definition for the particular OS
>> to see if it still matches the expectations of their program.
>>
>> VMS has about three such calls, with varying effects.  Which one should
>> an Ada compiler invoke ?
> 
> That is an interesting point. I don't know VMS, but I would expect
> that the one that MDC is looking for can be chosen from that set.
> 
> How do these 3 vary?  Surely, one of these must be inline with what
> other O/S's provide.

Are you claiming that all operating systems other than VMS are uniform
in what they provide ?

> The other API entries (if useful), can be provided
> by a Halt.Aux package or some other extension perhaps.

Presuming the VMS choices cover the universe of possibilities (doubtful),
what basis is there to think there is a uniform view of what is "the other"
method.

RE: terminate applications

[rleif]

This belongs in the Ada.POSIX package or a child package thereof. It should
not be part of the Ada ISO Standard; but should be in standard. Do we have a
mechanism for the compiler vendors or some SIGAda group to establish a
standard (collection of package specifications and requirements)?

Nick Roberts wrote "I think it might be valuable to add to the standard
library a procedure,

perhaps:

   procedure Ada.Unsafe_Terminate_Program;"

I believe that he has provided a good starting place.
Bob Leif 

My E-mail still goes to rleif@rleif.com

-----Original Message-----
From: Marin David Condic [mailto:nobody@noplace.com] 
Sent: Saturday, July 26, 2003 6:16 AM
To: comp.lang.ada@ada.eu.org
Subject: Re: terminate applications

The critical point being that if you *don't* give the programmer the 
choice, he'll just do an end-run around you anyway and resent the fact 
that he has to go outside the language to get what he wants.

It's an OS operation and the programmer ought to be able to access the 
OS in a portable way - to whatever extent that is possible. It doesn't 
have to be part of the Ada standard if the Ada community can agree on 
building a conventional library that will be included in most/all compilers.

MDC


Warren W. Gay VE3WWG wrote:
> 
> Give the programmer a choice. Document it as dangerous or
> unsupported, but give the programmer the choice. Management can
> dictate it out of a project if it needs to.
> 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jast.mil/

Send Replies To: m c o n d i c @ a c m . o r g

     "In general the art of government consists in taking as
     much money as possible from one class of citizens to give
     to the other."

         --  Voltaire
======================================================================

Re: terminate applications

[Warren W. Gay VE3WWG]

"Larry Kilgallen" <Kilgallen@SpamCop.net> wrote in message news:etldVqgp8sE1@eisner.encompasserve.org...
> In article <FTwUa.367$XK4.14917@read1.cgocable.net>, "Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> writes:
> > "Larry Kilgallen" <Kilgallen@SpamCop.net> wrote in message news:$TwrUBtoh25l@eisner.encompasserve.org...
> >> In article <3F227982.30204@noplace.com>, Marin David Condic <nobody@noplace.com> writes:
> >> > O.K., but what is wrong with saying that most operating systems provide
> >> > some means of immediate process termination in the form of a system call
> >> > and that Ada ought to have a portable and common binding to that (and
> >> > other) OS procedures?
> >>
> >> What is wrong is that not all operating systems define those facilities
> >> in the same way.  Ada programmers moving such code from one platform to
> >> another should be forced to read the definition for the particular OS
> >> to see if it still matches the expectations of their program.
> >>
> >> VMS has about three such calls, with varying effects.  Which one should
> >> an Ada compiler invoke ?
> >
> > That is an interesting point. I don't know VMS, but I would expect
> > that the one that MDC is looking for can be chosen from that set.
> >
> > How do these 3 vary?  Surely, one of these must be inline with what
> > other O/S's provide.
>
> Are you claiming that all operating systems other than VMS are uniform
> in what they provide ?

I made no claim. I asked a question.

> > The other API entries (if useful), can be provided
> > by a Halt.Aux package or some other extension perhaps.
>
> Presuming the VMS choices cover the universe of possibilities (doubtful),
> what basis is there to think there is a uniform view of what is "the other"
> method.

How many ways would you expect there to be in this "universe of program
terminations"?  You seem to be implying that this could be huge (and thus
a problem). I doubt that even more than your doubt, so there ;-)

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

Re: terminate applications

[Larry Kilgallen]

In article <JrBUa.447$XK4.24411@read1.cgocable.net>, "Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> writes:
> "Larry Kilgallen" <Kilgallen@SpamCop.net> wrote in message news:etldVqgp8sE1@eisner.encompasserve.org...
>> In article <FTwUa.367$XK4.14917@read1.cgocable.net>, "Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> writes:

>> > The other API entries (if useful), can be provided
>> > by a Halt.Aux package or some other extension perhaps.
>>
>> Presuming the VMS choices cover the universe of possibilities (doubtful),
>> what basis is there to think there is a uniform view of what is "the other"
>> method.
> 
> How many ways would you expect there to be in this "universe of program
> terminations"?  You seem to be implying that this could be huge (and thus
> a problem). I doubt that even more than your doubt, so there ;-)

It only takes two to cause a problem:

	One set of semantics supported by one group of operating systems.

	Another set of semantics supported by another group of operating
	systems.

So which of those should be chosen for operating systems on which either
set of semantics is supported by the operating system ?  Certainly that
should be part of the definition, rather than having two separate Ada
implementations do it differently on the same operating system.  Even
a loose "do what you can" definition is inadequate in that situation.

Re: terminate applications

[Marin David Condic]

O.K. but that is just making a case for why we need a library of common 
stuff outside of the ARM. I'll agree that there are all sorts of useful 
things that are difficult to specify to a sufficient level of detail to 
make them suitable for an ISO standard. But if the alternative is to say 
"Go roll your own..." or "You can find that in one or more of fifty 
libraries lying around the internet somewhere..." then I think it is 
unacceptable. You want to know that the code you wrote is making a call 
to something that will be supported in some fashion on most platforms by 
most compilers without having to make source code changes.

If we had a conventional library ("Provisional Standard" was the name 
suggested by Dr. Leif, but I'm willing to call it anything the community 
likes) that was adopted by most of the vendors, you could put a call 
such as this in there and not worry that nobody bothered to specify its 
behavior to some high level of detail or build a validation suite to be 
sure that it killed a program in exactly this particular manner with 
precisely these side effects. It would just exist in the library as a 
portable abstraction for the OS call and it does whatever happens when 
the OS call executes. No updates to the ARM, flexible implementation 
allowed, everybody can build portable code, no rigorous and costly 
validation procedures, Ada becomes more useful to everyone, everybody 
wins. I can't see how that would be a bad thing.

MDC



Nick Roberts wrote:
> 
> I think this suggestion makes it clear that: the semantics of such a
> procedure would be difficult to define, and impossible to enforce or test;
> it truly could be really dangerous in some environments. You might consider
> all the above a bit too much to add to the RM to be worth it.
> 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jast.mil/

Send Replies To: m c o n d i c @ a c m . o r g

     "In general the art of government consists in taking as
     much money as possible from one class of citizens to give
     to the other."

         --  Voltaire
======================================================================

Re: terminate applications

[Marin David Condic]

Well, provided that we're not talking about putting it into the ARM but 
creating a conventional Ada library that is shipped with most compilers 
(in source code, of course) then this isn't really as much of a problem 
as it might appear. You create a general "Kill" subprogram and connect 
it to the most popular or convenient call you have, and then for 
specific OS's that may have some bizarre twists and alternate calls, you 
create some sort of child package or other extension for those cases. At 
least it would be portable across all VMS implementations while 
providing a general solution for everything else. Since it would be in 
source, you could modify which call you use at your own risk.

MDC



Larry Kilgallen wrote:
> 
> 
> What is wrong is that not all operating systems define those facilities
> in the same way.  Ada programmers moving such code from one platform to
> another should be forced to read the definition for the particular OS
> to see if it still matches the expectations of their program.
> 
> VMS has about three such calls, with varying effects.  Which one should
> an Ada compiler invoke ?


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jast.mil/

Send Replies To: m c o n d i c @ a c m . o r g

     "In general the art of government consists in taking as
     much money as possible from one class of citizens to give
     to the other."

         --  Voltaire
======================================================================

Re: terminate applications

[Warren W. Gay VE3WWG]

"Larry Kilgallen" <Kilgallen@SpamCop.net> wrote in message news:q5jLYypXp6Yg@eisner.encompasserve.org...
> In article <JrBUa.447$XK4.24411@read1.cgocable.net>, "Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> writes:
> > "Larry Kilgallen" <Kilgallen@SpamCop.net> wrote in message news:etldVqgp8sE1@eisner.encompasserve.org...
> >> In article <FTwUa.367$XK4.14917@read1.cgocable.net>, "Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> writes:
>
> >> > The other API entries (if useful), can be provided
> >> > by a Halt.Aux package or some other extension perhaps.
> >>
> >> Presuming the VMS choices cover the universe of possibilities (doubtful),
> >> what basis is there to think there is a uniform view of what is "the other"
> >> method.
> >
> > How many ways would you expect there to be in this "universe of program
> > terminations"?  You seem to be implying that this could be huge (and thus
> > a problem). I doubt that even more than your doubt, so there ;-)
>
> It only takes two to cause a problem:

What problem? We are talking about process/thread termination
here.

> One set of semantics supported by one group of operating systems.
>
> Another set of semantics supported by another group of operating
> systems.

The only ones that I know about (which exclude VMS) are pretty plain
and easy to choose from!

> So which of those should be chosen for operating systems on which either
> set of semantics is supported by the operating system ?  Certainly that
> should be part of the definition, rather than having two separate Ada
> implementations do it differently on the same operating system.  Even
> a loose "do what you can" definition is inadequate in that situation.

You'll need to provide some VMS specifics that demonstrate a real
problem. Otherwise, I fail to see a problem.

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

Re: terminate applications

[Larry Kilgallen]

In article <BVXUa.969$XK4.65277@read1.cgocable.net>, "Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> writes:
> "Larry Kilgallen" <Kilgallen@SpamCop.net> wrote in message news:q5jLYypXp6Yg@eisner.encompasserve.org...
>> In article <JrBUa.447$XK4.24411@read1.cgocable.net>, "Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> writes:


>> > How many ways would you expect there to be in this "universe of program
>> > terminations"?  You seem to be implying that this could be huge (and thus
>> > a problem). I doubt that even more than your doubt, so there ;-)
>>
>> It only takes two to cause a problem:
> 
> What problem? We are talking about process/thread termination
> here.
> 
>> One set of semantics supported by one group of operating systems.
>>
>> Another set of semantics supported by another group of operating
>> systems.
> 
> The only ones that I know about (which exclude VMS) are pretty plain
> and easy to choose from!
> 
>> So which of those should be chosen for operating systems on which either
>> set of semantics is supported by the operating system ?  Certainly that
>> should be part of the definition, rather than having two separate Ada
>> implementations do it differently on the same operating system.  Even
>> a loose "do what you can" definition is inadequate in that situation.
> 
> You'll need to provide some VMS specifics that demonstrate a real
> problem. Otherwise, I fail to see a problem.

From http://h71000.www7.hp.com/doc/731FINAL/4527/4527pro_037.html#jun_194

	Do you want to call user mode exit handlers ?
	Do you want to call supervisor mode exit handlers ?
	Do you want to call executive mode exit handlers ?
	Do you want to call kernel mode exit handlers ?

I would expect the only exit handlers provided by Ada implementations
would be in user mode, but I cannot guarantee that for all possible
Ada implementations.  RMS exit handlers are mostly in executive
mode, although I suppose some might be in kernel mode.  How much
consistency do you want in the files the program had open? (Hint,
it can depend on whether you were doing asynchronous output or
using write-behind.)

From http://h71000.www7.hp.com/doc/731FINAL/4527/4527pro_050.html#jun_266

	Do you really want to stop the process, or just the program ?
	Returning to DCL would be desired by most users who had invoked
	a program interactively, and by many who are running a program
	in a batch job or other command procedure environment.

Or would you like to write a process dump file for later analysis ?

Re: terminate applications

[Dmitry A. Kazakov]

On Fri, 25 Jul 2003 22:58:53 -0400, "Warren W. Gay VE3WWG"
<ve3wwg@cogeco.ca> wrote:

>"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message news:bluvhvsr5kagtd9ksjdlpasf2iamcgu67v@4ax.com...
>> On Thu, 24 Jul 2003 10:54:51 -0400, "Warren W. Gay VE3WWG"
>> <ve3wwg@cogeco.ca> wrote:
>>
>> Now, how this can support any need to incorporate that buggy API into
>> the standard?
>
>You are labelling it a "buggy API". I see this as a legitamate
>function. For example, if an some internal assertion fails, it may
>be highly desireable to have the whole application be "canned"
>immediately, without a shutdown (which might inflict further damage).
>
>The problem as I see it, is that there is a very strong tension between
>the embedded/rocket/life-threatening developers and those that write
>much more mundane applications. I feel this same tension is rearing
>its head here. If Ada is to gain wider exceptance, you need to take
>those blinkers off. ;-)

What I am doing right now, is reviewing design of a C++ Windows
application which hangs upon exit! (:-)) The reason was unknown, so a
clever decision was made - just to wait a bit on application exit and
then if it is still active to kill it. A fine design? (:-)) Not at
all! Because it has 10+ DLLs and opens 20+ devices of various types.
So after a suicide, things are going strange, very strange. Do you
really want to legitimize such things in Ada?

>The embedded people don't want it because they don't want it used (to
>that I say fine, don't use it!)  Ravenscar avoids a large portion
>of Ada features that it considers "unsafe". What harm can one more
>"feature" bring if it is correctly documented?

Nobody reads documentation. (:-))

However, the place where a feature appears is already a sort of
documentation. When it appears in ARM body, then it is safe. In ARM
annex it could be a little less safe. In the package
Crappy.Windows.API it is, you'll get, what you asked for! (:-))

>To use an analogy you want to ban emergency brakes because they're
>weak, and almost useless. Yet every car in North America must have
>one.  I think having the choice of an emergency brake makes sense.
>No one is suggesting that you should use it, or that it be recommended.
>It merely should exist to offer a choice for those practical
>situations where it might be useful and valid.

No disagreement. But what I want, is to keep a sort of "sandbox"
design. Features of different safety levels should be put in different
boxes. From this point of view, an unconditional termination just does
not belong to the box of Ada standard. But it still may have a place
in OS-specific bindings.

---
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de

Re: terminate applications

[Warren W. Gay VE3WWG]

Dmitry A. Kazakov wrote:
> On Fri, 25 Jul 2003 22:58:53 -0400, "Warren W. Gay VE3WWG"
> <ve3wwg@cogeco.ca> wrote:
>>"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message news:bluvhvsr5kagtd9ksjdlpasf2iamcgu67v@4ax.com...
>>
>>>On Thu, 24 Jul 2003 10:54:51 -0400, "Warren W. Gay VE3WWG"
>>><ve3wwg@cogeco.ca> wrote:
>>>
>>>Now, how this can support any need to incorporate that buggy API into
>>>the standard?
>>
>>You are labelling it a "buggy API". I see this as a legitamate
>>function. For example, if an some internal assertion fails, it may
>>be highly desireable to have the whole application be "canned"
>>immediately, without a shutdown (which might inflict further damage).
>>
>>The problem as I see it, is that there is a very strong tension between
>>the embedded/rocket/life-threatening developers and those that write
>>much more mundane applications. I feel this same tension is rearing
>>its head here. If Ada is to gain wider exceptance, you need to take
>>those blinkers off. ;-)
> 
> What I am doing right now, is reviewing design of a C++ Windows
> application which hangs upon exit! (:-)) The reason was unknown, so a
> clever decision was made - just to wait a bit on application exit and
> then if it is still active to kill it. A fine design? (:-)) Not at
> all! Because it has 10+ DLLs and opens 20+ devices of various types.
> So after a suicide, things are going strange, very strange. Do you
> really want to legitimize such things in Ada?

Fine, then statically link it ;-)  I understand what you're saying (I am
not a win32 fan myself).  Under UNIX, this sort of thing is less of an
issue. Perhaps the "issue" is unsolvable under win32.

>>The embedded people don't want it because they don't want it used (to
>>that I say fine, don't use it!)  Ravenscar avoids a large portion
>>of Ada features that it considers "unsafe". What harm can one more
>>"feature" bring if it is correctly documented?
> 
> Nobody reads documentation. (:-))

I see the smiley, but who's problem is that? ;-)

> However, the place where a feature appears is already a sort of
> documentation. When it appears in ARM body, then it is safe. In ARM
> annex it could be a little less safe. In the package
> Crappy.Windows.API it is, you'll get, what you asked for! (:-))

This naming convention at least places the correct blame 8-)

>>To use an analogy you want to ban emergency brakes because they're
>>weak, and almost useless. Yet every car in North America must have
>>one.  I think having the choice of an emergency brake makes sense.
>>No one is suggesting that you should use it, or that it be recommended.
>>It merely should exist to offer a choice for those practical
>>situations where it might be useful and valid.
> 
> No disagreement. But what I want, is to keep a sort of "sandbox"
> design. Features of different safety levels should be put in different
> boxes. From this point of view, an unconditional termination just does
> not belong to the box of Ada standard. But it still may have a place
> in OS-specific bindings.

I won't disagree here, and have already suggested in other posts that
as a compromise, that a pragma might be in order to allow/disallow
such a "feature".
-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: terminate applications

[Marin David Condic]

Really, the fact that some feature can be used in a dangerous way should 
not be the issue. It has never been the least bit hard in *any* language 
to write software that behaves badly. The issue ought to be one of 
providing a common interface to normal OS services - process termination 
with extreme prejudice being one of them. I can see a thousand good 
reasons not to include everything under the sun in the ARM, so I'm O.K. 
with saying let's not try to stick this feature in there. But that 
doesn't mean it couldn't be provided by most vendors in a common way 
through a library everyone considered "conventional" for Ada, even 
though it wasn't in the standard.

You can't hide the OS calls. People *will* use them. If you don't give 
the developers a common interface to them, they just do an end-run 
around you and then curse your name for making it difficult for them.

MDC



Warren W. Gay VE3WWG wrote:
>>
>> What I am doing right now, is reviewing design of a C++ Windows
>> application which hangs upon exit! (:-)) The reason was unknown, so a
>> clever decision was made - just to wait a bit on application exit and
>> then if it is still active to kill it. A fine design? (:-)) Not at
>> all! Because it has 10+ DLLs and opens 20+ devices of various types.
>> So after a suicide, things are going strange, very strange. Do you
>> really want to legitimize such things in Ada?
> 
> 
> Fine, then statically link it ;-)  I understand what you're saying (I am
> not a win32 fan myself).  Under UNIX, this sort of thing is less of an
> issue. Perhaps the "issue" is unsolvable under win32.
> 

-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jast.mil/

Send Replies To: m c o n d i c @ a c m . o r g

     "In general the art of government consists in taking as
     much money as possible from one class of citizens to give
     to the other."

         --  Voltaire
======================================================================

Re: terminate applications

[Hyman Rosen]

Marin David Condic wrote:
> You can't hide the OS calls. People *will* use them. If you don't give 
> the developers a common interface to them, they just do an end-run 
> around you and then curse your name for making it difficult for them.

This might be a good time to send people over to check out
<http://www.jowsey.com/java/sim1620/>. Start up the simulator,
and look on the lower left, where you will find the big red
"PULL FOR EMERGENCY" button.

Re: terminate applications

[Warren W. Gay VE3WWG]

Hyman Rosen wrote:
> Marin David Condic wrote:
> 
>> You can't hide the OS calls. People *will* use them. If you don't give 
>> the developers a common interface to them, they just do an end-run 
>> around you and then curse your name for making it difficult for them.
> 
> 
> This might be a good time to send people over to check out
> <http://www.jowsey.com/java/sim1620/>. Start up the simulator,
> and look on the lower left, where you will find the big red
> "PULL FOR EMERGENCY" button.

The IBM-1130 that I spent 4 years on, had a big Red emergency
pull button. There was many a night were curiosity brought me
close to trying it but besides pulling the power,
I was not sure of its precise "semantics" ;-)  I was always
afraid that a service call might be required as follow up, so
I refrained from discovering those semantics.
-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: terminate applications

[Warren W. Gay VE3WWG]

Larry Kilgallen wrote:
> In article <BVXUa.969$XK4.65277@read1.cgocable.net>, "Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> writes:
>>"Larry Kilgallen" <Kilgallen@SpamCop.net> wrote in message news:q5jLYypXp6Yg@eisner.encompasserve.org...
>>>In article <JrBUa.447$XK4.24411@read1.cgocable.net>, "Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> writes:
...
>>>So which of those should be chosen for operating systems on which either
>>>set of semantics is supported by the operating system ?  Certainly that
>>>should be part of the definition, rather than having two separate Ada
>>>implementations do it differently on the same operating system.  Even
>>>a loose "do what you can" definition is inadequate in that situation.
>>
>>You'll need to provide some VMS specifics that demonstrate a real
>>problem. Otherwise, I fail to see a problem.
> 
> 
> From http://h71000.www7.hp.com/doc/731FINAL/4527/4527pro_037.html#jun_194
> 
> 	Do you want to call user mode exit handlers ?
> 	Do you want to call supervisor mode exit handlers ?
> 	Do you want to call executive mode exit handlers ?
> 	Do you want to call kernel mode exit handlers ?
> 
> I would expect the only exit handlers provided by Ada implementations
> would be in user mode, but I cannot guarantee that for all possible
> Ada implementations.  RMS exit handlers are mostly in executive
> mode, although I suppose some might be in kernel mode.  How much
> consistency do you want in the files the program had open? (Hint,
> it can depend on whether you were doing asynchronous output or
> using write-behind.)

Sorry for the delay, in getting back to this..

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 would expect, that you wouldn't want to tamper with the rest.

File integrity.. Who cares?

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

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.

> From http://h71000.www7.hp.com/doc/731FINAL/4527/4527pro_050.html#jun_266
> 
> 	Do you really want to stop the process, or just the program ?
> 	Returning to DCL would be desired by most users who had invoked
> 	a program interactively, and by many who are running a program
> 	in a batch job or other command procedure environment.
> 
> Or would you like to write a process dump file for later analysis ?

Again, asking for "dumps" is adding to the original requirements and
so this is a non-issue, as OP clearly did not request for a dump
(admitedly, in a debugging environment, this might be useful).

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?

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

Re: terminate applications

[Larry Kilgallen]

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

> I would expect, that you wouldn't want to tamper with the rest.
> 
> File integrity.. Who cares?

Those two statements are in conflict.

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

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

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

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.

Re: terminate applications

[Warren W. Gay VE3WWG]

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

Re: terminate applications

[Larry Kilgallen]

In article <H8yWa.10610$Cx4.1029460@news20.bellglobal.com>, "Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> writes:
> Larry Kilgallen wrote:

> Everyone keeps trying to complicate a very simple requirement:
> 
>   - terminate with prejudice:
>      - process
>      - and all accompanying threads
>      - no other guarantees requested or desired

So it is permissible to terminate subprocesses as a side effect ?

Or is it _required_ to terminate subprocesses as a side effect ?

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

I am not suggesting a requirement that the call do X.  What I would
like to see is _guidance_ as to whether the call should do X in those
environments where an X-or-not decision is part of the operation of
terminating a process (or was it a program).

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

Yes (but not in the same processor mode).

> It sounds a bit like DOS command interpreter and
> executable living in the same address space together.

I have no experience with DOS (at least not the PC version to which
I presume you are referring - if you meant PDP-11 DOS/Batch or System
360 DOS I figure you would have so indicated).

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

But there is no reason to expect (on VMS anyway) that terminating the
program would leave threads running, because that is tautologically
impossible in user mode.

So if stopping all threads is your requirement, the definition
should not say "terminate the process".  The process should live
(in a DCL environment on VMS).

Or is there some ARM definition of "process" at odds with that for VMS ?