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

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

[chris.danx]

drmed wrote:
> hi,
> Is there a function which quit/exit/end a program? -> whitout using
> the signals (like SIGINT ... etc).
> Only a one-line function.

Think GNAT has a procedure to terminate if that's the compiler in 
question.  hang on...

Yep, in gnat.os_lib there is a procedure gnat.os_lib.OS_Exit which quits 
a program.

Other compilers might provide a similar function.



-- 
for personal replies change 'spamoff' to 'chris'

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

[David C. Hoos]

In the main program procedure, "return" will do it.
----- Original Message ----- 
From: "drmed" <jonas.gasser@dataflow.ch>
Newsgroups: comp.lang.ada
To: <comp.lang.ada@ada.eu.org>
Sent: Tuesday, August 13, 2002 9:27 AM
Subject: stupid question: how can I finish a program?


> hi,
> Is there a function which quit/exit/end a program? -> whitout using
> the signals (like SIGINT ... etc).
> Only a one-line function.
> thanks
> 
> jonas
> _______________________________________________
> comp.lang.ada mailing list
> comp.lang.ada@ada.eu.org
> http://ada.eu.org/mailman/listinfo/comp.lang.ada
> 

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

[Adam Beneschan]

"David C. Hoos" <david.c.hoos.sr@ada95.com> wrote in message news:<mailman.1029249602.10046.comp.lang.ada@ada.eu.org>...
> In the main program procedure, "return" will do it.

If you're not in the main program, a possibility is to define an
exception Fatal_Error_Detected or something like that in a library
package; then "raise Fatal_Error_Detected" can be used at points when
you want to exit the program.  In the main program, add an exception
handler:

    begin
        ...
    exception
	when Fatal_Error_Detected =>
	    null;   -- OR you can add cleanup code if necessary
    end Main_Program;

Also, if there's any other procedure in the program in which you want
to perform cleanup code before exiting, you can add an exception
handler to the procedure:

    exception
	when Fatal_Error_Detected =>
	    <cleanup code>
            raise;


> > hi,
> > Is there a function which quit/exit/end a program? -> whitout using
> > the signals (like SIGINT ... etc).
> > Only a one-line function.
> > thanks

				-- Adam

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

[Robert C. Leif]

From: Bob Leif
To: Chris Dank et al.
Since it is quite common to terminate a commercial program after an
exception is raised, it would be quite useful if Ada 200? would include
a standard procedure for this. 

-----Original Message-----
From: comp.lang.ada-admin@ada.eu.org
[mailto:comp.lang.ada-admin@ada.eu.org] On Behalf Of chris.danx
Sent: Tuesday, August 13, 2002 7:38 AM
To: comp.lang.ada@ada.eu.org
Subject: Re: stupid question: how can I finish a program?

drmed wrote:
> hi,
> Is there a function which quit/exit/end a program? -> whitout using
> the signals (like SIGINT ... etc).
> Only a one-line function.

Think GNAT has a procedure to terminate if that's the compiler in 
question.  hang on...

Yep, in gnat.os_lib there is a procedure gnat.os_lib.OS_Exit which quits

a program.

Other compilers might provide a similar function.



-- 
for personal replies change 'spamoff' to 'chris'

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

[Wes Groleau]

> Since it is quite common to terminate a commercial program after an
> exception is raised, it would be quite useful if Ada 200? would include
> a standard procedure for this.

This has been in Ada all along.

If there is no exception handler, the program terminates.

If the only exception handler is at the top level,
the program terminates after executing the handler.

If there is a lower-level exception handler, you convert
to one of the above situations by adding "raise;"
to the handler.

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

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

[Robert C. Leif]

From: Bob Leif
To: Wes Groleau
Although, you are technically correct, this termination may occur much
later than one desires. A large amount of extraneous output can be
produced before termination. I normally store the information produced
by an exception in a log file. I would like to minimize the size of this
file, in order to quickly find my mistakes.

-----Original Message-----
From: comp.lang.ada-admin@ada.eu.org
[mailto:comp.lang.ada-admin@ada.eu.org] On Behalf Of Wes Groleau
Sent: Tuesday, August 13, 2002 7:07 PM
To: comp.lang.ada@ada.eu.org
Subject: Re: stupid question: how can I finish a program?


> Since it is quite common to terminate a commercial program after an
> exception is raised, it would be quite useful if Ada 200? would
include
> a standard procedure for this.

This has been in Ada all along.

If there is no exception handler, the program terminates.

If the only exception handler is at the top level,
the program terminates after executing the handler.

If there is a lower-level exception handler, you convert
to one of the above situations by adding "raise;"
to the handler.

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

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

[Emil Moholth]

"drmed" <jonas.gasser@dataflow.ch> wrote in message
news:c923f575.0208130627.479e0b3d@posting.google.com...
> hi,
> Is there a function which quit/exit/end a program? -> whitout using
> the signals (like SIGINT ... etc).
> Only a one-line function.
> thanks
>
> jonas

This is supported as part of the Annex C - Systems programming.

C.7.1 (9) The effect of Abort_Task is the same as the abort_statement for
the task identified by T. In addition, if T identifies the environment task,
the entire partition is aborted, See E.1

So this leaves us with this single line in the main procedure.

Ada.Task_Identification.Abort_Task (
      T => Ada.Task_Identification.Current_Task );

If some library unit maintains some persistent state extra measures is
needed to ensure a correct state before executing the above statement. I
would feel a lot more safe if I could ensure termination of all tasks in the
partition as part of the partition termination. Then the partition would
terminate normally without any such statement.

emilm

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

[Martin Dowie]

"drmed" <jonas.gasser@dataflow.ch> wrote in message
news:c923f575.0208130627.479e0b3d@posting.google.com...
> hi,
> Is there a function which quit/exit/end a program? -> whitout using
> the signals (like SIGINT ... etc).
> Only a one-line function.

I think this may have been covered in cla a few times (Dec 2000?)
but you could do something like:

package Program is

   procedure Kill;

end Program;

with Ada.Task_Identification; use Ada.Task_Identification;
package body Program is
   Environment_Task : Task_ID := Current_Task;

   procedure Kill is
   begin
      Abort_Task (T => Environment_Task);
   end Kill;
end Program;

then call "Program.Kill" from pretty much anywhere else in
your program.

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

[Wes Groleau]

> > If there is no exception handler, the program terminates.
>
> Although, you are technically correct, this termination may occur much
> later than one desires.  A large amount of extraneous output can be

Point taken.

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

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

[Marin D. Condic]

This is a question that seems to come up fairly regularly: "Is there a
standard way of forcing an Ada program to terminate?" Since the current
answer is "No", but the question keeps coming up, it would seem like proper
fodder for an Ada 0x. It shouldn't be hard to incorporate something into the
language as either a standard procedure or even some kind of use of existing
keywords. I can't imagine it being difficult to implement since most OS's
that support processes have some facility for killing a process and on an
embedded machine without an OS, it hardly matters what you do (infinite
loop?). There might be issues if you wanted an *orderly* shutdown, but I
don't see that being the place to use some flavor of a "terminate all;"
statement. (How can the compiler decide what is "orderly" and how can it
tell that in the process of being "orderly" the program doesn't run off to
Flanders and never return? Better to leave that in the hands of the
programmer.)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com

Enabling Digital.
Our Vision is to be the biggest supplier worldwide of digital gateway
technology.
www.pacemicro.com

"Robert C. Leif" <rleif@rleif.com> wrote in message
news:mailman.1029282843.28085.comp.lang.ada@ada.eu.org...
> From: Bob Leif
> To: Chris Dank et al.
> Since it is quite common to terminate a commercial program after an
> exception is raised, it would be quite useful if Ada 200? would include
> a standard procedure for this.
>

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

[Marin D. Condic]

Not really. It works for single threaded programs, but not for multi
threaded programs. Try it with tasks. Try having one task determine that the
whole program should shut down. There is no "shoot this process in the head
right this instant and I really mean it!" instruction in Ada. Not a
"standard" one, at least. Not one that will work with all possible Ada
programs.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com

Enabling Digital.
Our Vision is to be the biggest supplier worldwide of digital gateway
technology.
www.pacemicro.com

"Wes Groleau" <wesgroleau@despammed.com> wrote in message
news:3D59BB4C.AA21BDA@despammed.com...
>
> This has been in Ada all along.
>
> If there is no exception handler, the program terminates.
>
> If the only exception handler is at the top level,
> the program terminates after executing the handler.
>
> If there is a lower-level exception handler, you convert
> to one of the above situations by adding "raise;"
> to the handler.
>
> --
> Wes Groleau
> http://freepages.rootsweb.com/~wgroleau

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

[Marin D. Condic]

That would be a good answer except that it doesn't work in all cases. It is
possible for tasks to be in a state where they can't be aborted. There are
corner cases in the language rules that will prevent the statement you show
from terminating the program.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com

Enabling Digital.
Our Vision is to be the biggest supplier worldwide of digital gateway
technology.
www.pacemicro.com

"Emil Moholth" <emil.moholth@kongsberg.com> wrote in message
news:3d59fb69@193.71.169.73...
>
> This is supported as part of the Annex C - Systems programming.
>
> C.7.1 (9) The effect of Abort_Task is the same as the abort_statement for
> the task identified by T. In addition, if T identifies the environment
task,
> the entire partition is aborted, See E.1
>
> So this leaves us with this single line in the main procedure.
>
> Ada.Task_Identification.Abort_Task (
>       T => Ada.Task_Identification.Current_Task );
>
> If some library unit maintains some persistent state extra measures is
> needed to ensure a correct state before executing the above statement. I
> would feel a lot more safe if I could ensure termination of all tasks in
the
> partition as part of the partition termination. Then the partition would
> terminate normally without any such statement.
>
> emilm
>
>

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

[Simon Wright]

Wes Groleau <wesgroleau@despammed.com> writes:

> If there is no exception handler, the program terminates.
> 
> If the only exception handler is at the top level,
> the program terminates after executing the handler.
> 
> If there is a lower-level exception handler, you convert
> to one of the above situations by adding "raise;"
> to the handler.

This is only true if there are no tasks (apart from the environment
task) involved.

   procedure Term is
      task T;
      task body T is
      begin
         delay 5.0;
      end T;
   begin
      raise Constraint_Error;
   end Term;

returns you to the command prompt after 5 seconds.

   smaug[4]$ time ./term

   raised CONSTRAINT_ERROR : term.adb:8

   real    0m5.145s
   user    0m0.000s
   sys     0m0.000s

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

[Robert Dewar]

Wes Groleau <wesgroleau@despammed.com> wrote in message news:<3D59BB4C.AA21BDA@despammed.com>...
> > Since it is quite common to terminate a commercial program after an
> > exception is raised, it would be quite useful if Ada 200? would include
> > a standard procedure for this.

Seems redundant, just abort the environment task, that's
the simplest suicide model.

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

[Michael Bode]

dewar@gnat.com (Robert Dewar) writes:

> Seems redundant, just abort the environment task, that's
> the simplest suicide model.

I had a similar problem, but my programm has a server task which most
of the time waits on blocking socket functions (Accept or String'Read
from a socket). I tried raising an exception in the main task,
killing the server task with abort or the select ... abort
construct, but this didn't work. Probably I should't expect this to
work. So I just kill the program with Gnat.OS_Lib.OS_Exit. I wonder if
there is a way to do this with standard functions.

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

[tmoran]

> Seems redundant, just abort the environment task, that's
> the simplest suicide model.
  But it doesn't accomplish the "murder the kids, then yourself"
multi-task suicide.
  What are the important differences between the environment task
aborting itself vs having it execute:
  declare
    Emergency_Exit : exception;
  begin
    raise Emergency_Exit;
  end;

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

[Wes Groleau]

> > If there is no exception handler, the program terminates.
> > [etc.]
> 
> This is only true if there are no tasks (apart from the environment
> task) involved.

Oops.  (sheepish grin)  If I can temporarily forget
that Ada has tasking, I must have been away too long!

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

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

[tmoran]

> forcing an Ada program to terminate?"

  The problem is that "terminate" is ambiguous.  Do you mean terminate
the current task?  The task and all its children?  All tasks in the
program?  Do you want Finalization to occur or not occur?  All, or just
some?  If the code module that wants to terminate is in fact a reusable
component, should it really terminate the whole program and all its
tasks, or just the single component.  What should happen when a
procedure designed as a whole program is used instead as a single
procedure in some larger program.  Should the larger program terminate?
  I'm inclined toward raising an unhandled exception.  That gives the
overall program the option of an "others" handler to limit the "extent
of termination".  Of course it also means "others" shouldn't be used
casually.  One problem with a piece of code that aborts the environment
task is that it might be called from some other task, which would then
continue, with great confusion for all.
  Probably most people asking the question just want to terminate the
single (environment) task in the simple program, with Finalization
occurring, and an unhandled exception does that nicely.

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

[Robert Dewar]

tmoran@acm.org wrote in message news:<gPG69.5381$Ot1.248134805@newssvr13.news.prodigy.com>...
> But it doesn't accomplish the "murder the kids, then 
> yourself" multi-task suicide.

Of course it does (read the RM!)

> What are the important differences between the 
> environment task aborting itself vs having it execute:
>   declare
>     Emergency_Exit : exception;
>   begin
>     raise Emergency_Exit;
>   end;

Obvious difference: only the environment task can usefully
do the latter, whereas anyone can abort the environment
task (i.e. any task).

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

[Marin D. Condic]

Its hard to tell if my other posts are making it out there in a timely
fashion. I made comments elsewhere in more detail about what I think needs
to happen. But in case its not clear or getting out there, I'll take another
shot at it.

Since you can already raise an exception to terminate a given thread and you
can do various other forms of task termination and you have a variety of
ways of dealing with finalization, etc. I don't really see any need to
re-address these things in any new language feature. The one thing you can't
do is shoot any arbitrary Ada program square in the head from anywhere in
the code and shut it down totally no matter what state it is in. In
operating system parlance, we need a way of killing the process that is
running the program. Do not pass go. Do not collect $200. :-) (The need to
do this may not be an every day occurence, but it happens enough that its
worth having a way of addressing it.)

Shutting down the environment task comes close, except that it won't
terminate *all* Ada programs. Tasks can get into states wherein they cannot
be aborted and the language rules are such that you're still left needing to
hit ctrl-C if you want the program to shut down. So it would be a good idea
to incorporate a standard procedure that would need to do nothing more than
call whatever OS function is available to cause the encasing process to be
killed. (Are there any workstation-ish OS's that *don't* provide a mechanism
for killing a process?) If there is no OS then the whole concept of
"terminating the process" doesn't make much sense, since there is nothing to
return control to. In this case you just insert an infinite loop - the
program is effectively stopped.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com

Enabling Digital.
Our Vision is to be the biggest supplier worldwide of digital gateway
technology.
www.pacemicro.com

<tmoran@acm.org> wrote in message
news:cHR69.6930$VV.242093357@newssvr21.news.prodigy.com...
>
>   The problem is that "terminate" is ambiguous.  Do you mean terminate
> the current task?  The task and all its children?  All tasks in the
> program?  Do you want Finalization to occur or not occur?  All, or just
> some?  If the code module that wants to terminate is in fact a reusable
> component, should it really terminate the whole program and all its
> tasks, or just the single component.  What should happen when a
> procedure designed as a whole program is used instead as a single
> procedure in some larger program.  Should the larger program terminate?
>   I'm inclined toward raising an unhandled exception.  That gives the
> overall program the option of an "others" handler to limit the "extent
> of termination".  Of course it also means "others" shouldn't be used
> casually.  One problem with a piece of code that aborts the environment
> task is that it might be called from some other task, which would then
> continue, with great confusion for all.
>   Probably most people asking the question just want to terminate the
> single (environment) task in the simple program, with Finalization
> occurring, and an unhandled exception does that nicely.

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

[Warren W. Gay VE3WWG]

Marin D. Condic wrote:
...
> Since you can already raise an exception to terminate a given thread and you
> can do various other forms of task termination and you have a variety of
> ways of dealing with finalization, etc. I don't really see any need to
> re-address these things in any new language feature. The one thing you can't
> do is shoot any arbitrary Ada program square in the head from anywhere in
> the code and shut it down totally no matter what state it is in. 

Actually this same situation does come up at the operating system level
(UNIX anyway) at times. Imagine a process that is writing out a tape,
but the tape unit is hung up because of tape I/O errors (or driver bug),
or waiting a tape change etc.,
and you try to kill the process doing the tape write. The process stays
there, because control is still stuck within the kernel.

So some "smart aleck"
comes along and does a kill -9 on it, and this eliminates the process
alright -- but now the tape drive is dead until the next kernel reboot
(because the driver state is now all messed up).
This is an actual past experience I used to have with a SCO UNIX
platform, and that "smart aleck" was me ;-)

The basic message (besides avoiding kill -9) is that there will
always likely be situations where
stopping a process, task, or whatever is not always
immediately possible, without some "cost" associated with it.

In Windows, if you have opened some COM/DCOM objects and referenced
their various interfaces etc., by killing off the process/thread
prematurely will leave the referenced
COM objects referenced. Unlike UNIX where there is a SEM_UNDO
for semaphores, there is no such recovery under the M$ regime.
Those COM/DCOM objects and interfaces stay referenced until the
next reboot -- not a good thing for servers.

I guess what I am suggesting is that it is better to build in a shutdown
protocol, to keep things sane, than it is to rely on a "nuke-em" type
of approach.
-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

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

[Alfred Hilscher]

Michael Bode schrieb:
> 
> dewar@gnat.com (Robert Dewar) writes:
> 
> > Seems redundant, just abort the environment task, that's
> > the simplest suicide model.
> 
> I had a similar problem, but my programm has a server task which most
> of the time waits on blocking socket functions (Accept or String'Read
> from a socket).


Hi Michael,

I had a similar problem. I solved as follows: I have an extra
"shutdown-task" which is only responsible for "unblocking" the sockets
by calling "WSACancelBlockingCall" (OK windows only, but I think there
should be a similar function even on *x systems). This works fine, all
blocking calls are unblocked with the return code WSAEINTR.

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

[Robert Dewar]

"Marin D. Condic" <not.valid@acm.org> wrote in message news:<ajdnjb$k2k$1@nh.pace.co.uk>...

> There is no "shoot this process in the head
> right this instant and I really mean it!" instruction in 
> Ada. Not a "standard" one, at least. Not one that will 
> work with all possible Ada programs.

That's misleading. Aborting the environment task will work.
However, in the real world, we seldom have Ada programs,
instead we have mixtures of Ada and various libraries and
foreign languages, and in this case, you can't depend on
anything predefined in Ada to work, and the issue of immediate
termination becomes somewhat system dependent.

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

[tmoran]

>Its hard to tell if my other posts are making it out there in a timely
  It arrived from my news feed today (8/22), though I see it's date,
and the date it apparently arrived in Google Groups, was 8/16.  My
newsgroup 'service' is from SBC Pacific Bell in that internet backwater
known as Silicon Valley.

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

[Marin D. Condic]

Thanks for the comeback there, driver! :-)

My news server lives somewhere in England while I sit in Florida. So to make
it out to Silicone Valley it has to take the scenic route. Even at 186,000
Miles per second (not just a good idea - its the law!) it might take a
while - but six days? Periodically, there seems to be either big delays or
outright loss of messages going through our server. I'll ask our network
people to look at it. Thanks.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com

Enabling Digital.
Our Vision is to be the biggest supplier worldwide of digital gateway
technology.
www.pacemicro.com

<tmoran@acm.org> wrote in message
news:nMa99.5035$Z06.356526251@newssvr13.news.prodigy.com...
> >Its hard to tell if my other posts are making it out there in a timely
>   It arrived from my news feed today (8/22), though I see it's date,
> and the date it apparently arrived in Google Groups, was 8/16.  My
> newsgroup 'service' is from SBC Pacific Bell in that internet backwater
> known as Silicon Valley.

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

[Robert Dewar]

"Marin D. Condic" <not.valid@acm.org> wrote in message news:<ajdnck$k12$1@nh.pace.co.uk>...
> This is a question that seems to come up fairly regularly: "Is there a
> standard way of forcing an Ada program to terminate?" Since the current
> answer is "No"

No, the current answer is "Yes", you can abort the environment task.

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

[Marin D. Condic]

Disregarding some intersections of language rules brought up in this forum
in the not too distant past that indicate there are some circumstances under
which dependent tasks can't be aborted, I'll accept for the moment that this
is true. If that's the case, then I've got an Ada program that aborts the
environment task and doesn't terminate the program - something I can do
quite easily with a control-C. That kind of implies in my mind that either
A) Aborting the environment task is not equivalent to "Kill any Ada program
right now regardless of what it may be doing" or B) There is a bug in the
compiler. If "A" is the case, then it seems reasonable that perhaps Ada
could use a standard method of interfacing to the OS to kill the process or
otherwise come up with something that causes a program to terminate in all
circumstances.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com

Enabling Digital.
Our Vision is to be the biggest supplier worldwide of digital gateway
technology.
www.pacemicro.com

"Robert Dewar" <dewar@gnat.com> wrote in message
news:5ee5b646.0208241822.34540e8b@posting.google.com...
>
> No, the current answer is "Yes", you can abort the environment task.

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

[Robert A Duff]

dewar@gnat.com (Robert Dewar) writes:

> "Marin D. Condic" <not.valid@acm.org> wrote in message news:<ajdnck$k12$1@nh.pace.co.uk>...
> > This is a question that seems to come up fairly regularly: "Is there a
> > standard way of forcing an Ada program to terminate?" Since the current
> > answer is "No"
> 
> No, the current answer is "Yes", you can abort the environment task.

No, that doesn't do it.  I believe the original poster wants to kill the
program (really, the "partition", in Ada terms, or the "process", in OS
terms), even if some tasks are in an abort-deferred state.  Furthermore,
the desire is to skip finalization.  Aborting the env task doesn't do
that.

So I think it's true that Ada has no portable way of doing what was
desired.  Furthermore, I think it's a reasonable desire, in some rare
cases.

On the other hand, every OS has such a mechanism, and on most of them
it's called "exit".  That's portable enough, in practise.

- Bob

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

[Robert A Duff]

Dmitry A.Kazakov <mailbox@dmitry-kazakov.de> writes:

> For example? Abort without any defined clean-up warranties absolutely 
> nothing.
> 
> Otherwise, some sort of "finalization" should be defined. For instance: 
> known tasks killed, known memory returned. But (1) any sort of finalization 
> could still hang up.

If you're running under a proper operating system, then all resources
visible outside the program will be cleaned up when the program exits.
Therefore, there is no need for finalization to clean up such resources.
(I'm talking about the Ada finalization here.)  Certainly, "exit" will
kill all tasks in the program and recover all memory.  There is no need
for finalization to clean up resources internal to the program, either
-- the program is about to vanish.

*Some* kinds of finalization might be broken by "exit".  For example, if
some Finalize routine flushes a buffer to disk, and you want that buffer
flushed.  So you can't blithely call "exit" without some global
knowledge of how finalization is used in your program.

If you're not using an operating system then the story is very
different.

>... (2) How to define it in a portable way (= in language 
> terms)?

Seems pretty straightforward to me.  Just define a feature that halts
the program and doesn't run any finalization.  In an embedded system,
the appropriate implementation might be:

    <<Self>> goto Self;

- Bob

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

[Marin D. Condic]

Oh, and how could it be defined in a portable way? C does it with a couple
of standard functions. Ada can make standard subprograms too, so why not?
Probably (since it is an OS dependent thing and might not have meaning
outside the context of an OS) there should be some sort of standard package
like "Ada.OS_Services" that contained proccedure(s) to connect to whatever
the OS provides. (I hear something like this is in the works)

There can't be *that* many different ways of killing the process that a
reasonable compromise answer couldn't be found. What more would be needed
than a "Kill_The_Process (Optional_Integer_Return_Code_For_Unix_Freaks) ;"
call? Would it need to be dramatically different between Unix/Windows/Mac?
Would anyone care if it couldn't be implemented easily on some obscure OS?
Would the formal definition need to be any more complicated than:
"Implementation Defined - but we suggest that you make it do what any sane
person using the target OS would reasonably expect..."? It doesn't seem like
Rocket Science to me - nor does it sound like a horendous burden on the
compiler writers. The only real question could be "Is it reasonably useful
to have such an operation?" and I think the answer is "Yes".

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com

Enabling Digital.
Our Vision is to be the biggest supplier worldwide of digital gateway
technology.
www.pacemicro.com

"Dmitry A.Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:aki1tq$1ij38n$1@ID-77047.news.dfncis.de...
> could still hang up. (2) How to define it in a portable way (= in language
> terms)?
>
>

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

[Darren New]

Robert A Duff wrote:
> If you're running under a proper operating system, then all resources
> visible outside the program will be cleaned up when the program exits.

This is true only in the most trivial sense. If I have a program that
contacts a license manager (for example) and grabs the license, then aborts,
I could be in trouble. That's why license managers check for that sort of
failure. If I create a lock-file, that lock-file doesn't get cleaned up
(under UNIX, for example). 

Other OSes (like Amiga's OS) specifically don't clean up anything at all, as
this lets you do things like allocate memory, load a program into it, and
start it up and then exit yourself. You have to clean it up for yourself.

Some mainframe OSes leave the clean-up to the shell. It's the shell's
responsibility to free the memory and close the files. However, I'd expect
that one would count the shell as "part of the OS" in these systems.

So no, in general, a "proper" operating system doesn't clean up all visible
resources. Not even with exit() calls. :-)

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
   ** http://images.fbrtech.com/dnew/ **

Try our EbolaBurgers...
      So tender they melt in your mouth.

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

[Larry Kilgallen]

In article <3D6D00B9.60EECCFB@san.rr.com>, Darren New <dnew@san.rr.com> writes:
> Robert A Duff wrote:
>> If you're running under a proper operating system, then all resources
>> visible outside the program will be cleaned up when the program exits.
> 
> This is true only in the most trivial sense. If I have a program that
> contacts a license manager (for example) and grabs the license, then aborts,
> I could be in trouble. That's why license managers check for that sort of
> failure. If I create a lock-file, that lock-file doesn't get cleaned up
> (under UNIX, for example). 
> 
> Other OSes (like Amiga's OS) specifically don't clean up anything at all, as
> this lets you do things like allocate memory, load a program into it, and
> start it up and then exit yourself. You have to clean it up for yourself.
> 
> Some mainframe OSes leave the clean-up to the shell. It's the shell's
> responsibility to free the memory and close the files. However, I'd expect
> that one would count the shell as "part of the OS" in these systems.
> 
> So no, in general, a "proper" operating system doesn't clean up all visible
> resources. Not even with exit() calls. :-)

The "proper" operating system on my computer does.  The license manager
uses the Distributed Lock Manager and per-user licenses automatically
return to the pool on image rundown.

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

[Dmitry A.Kazakov]

Robert A Duff wrote:

> No, that doesn't do it.  I believe the original poster wants to kill the
> program (really, the "partition", in Ada terms, or the "process", in OS
> terms), even if some tasks are in an abort-deferred state.  Furthermore,
> the desire is to skip finalization.  Aborting the env task doesn't do
> that.
> 
> So I think it's true that Ada has no portable way of doing what was
> desired.  Furthermore, I think it's a reasonable desire, in some rare
> cases.

For example? Abort without any defined clean-up warranties absolutely 
nothing.

Otherwise, some sort of "finalization" should be defined. For instance: 
known tasks killed, known memory returned. But (1) any sort of finalization 
could still hang up. (2) How to define it in a portable way (= in language 
terms)?

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

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

[Larry Kilgallen]

In article <akin0p$fma$1@nh.pace.co.uk>, "Marin D. Condic" <not.valid@acm.org> writes:

> There can't be *that* many different ways of killing the process that a
> reasonable compromise answer couldn't be found. What more would be needed
> than a "Kill_The_Process (Optional_Integer_Return_Code_For_Unix_Freaks) ;"
> call? Would it need to be dramatically different between Unix/Windows/Mac?
> Would anyone care if it couldn't be implemented easily on some obscure OS?

As I recall, you had some VMS background, so VMS is not "obscure" :-)

	1. With what error code should one exit (odd numbers mean success) ?
	2. Do you want to run exit handlers in the executable image
	   and the various shareable images it invoked ?
	3. Do you want to run exit handling in the batch file that
	   is controlling the program ?

But you cannot avoid running the exit handlers associated with a
privileged shareable image.  It is possible to construct a pathelogical
case that will not kill the process since that would damage system
integrity.

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

[Robert A Duff]

Darren New <dnew@san.rr.com> writes:

> Robert A Duff wrote:
> > If you're running under a proper operating system, then all resources
> > visible outside the program will be cleaned up when the program exits.
> 
> This is true only in the most trivial sense. If I have a program that
> contacts a license manager (for example) and grabs the license, then aborts,
> I could be in trouble. That's why license managers check for that sort of
> failure.

So if it's checked for, what's the problem?

My point is that any process can be killed at any point.  The process
could execute an illegal instruction (Ada allows calls to machine code,
for example, and allows Unchecked_Conversion to pointers).  Or (in
Unix), you can "kill -9" it.  The OS has to recover from those nasties
without leaking resources.  So surely calling "exit" is no worse.

>... If I create a lock-file, that lock-file doesn't get cleaned up
> (under UNIX, for example). 

That's why I said, "So you can't blithely call "exit" without some global
knowledge of how finalization is used in your program."

A program that acquires lock files ought to be robust.  For example,
check whether a previous dead version of itself created the lock file.

> Other OSes (like Amiga's OS) specifically don't clean up anything at all, as
> this lets you do things like allocate memory, load a program into it, and
> start it up and then exit yourself. You have to clean it up for yourself.

I don't know Amiga, but it seems to me that if a crashed program causes
memory leaks, the OS is broken.

> Some mainframe OSes leave the clean-up to the shell. It's the shell's
> responsibility to free the memory and close the files. However, I'd expect
> that one would count the shell as "part of the OS" in these systems.

And one thing Unix does right is to make shells *not* part of the OS.

> So no, in general, a "proper" operating system doesn't clean up all visible
> resources. Not even with exit() calls. :-)

I guess it depends on what "proper" OS means.  I'm assuming hardware
memory protection, and an OS that takes advantage of that to reclaim
resources from crashed processes.

- Bob

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

[Darren New]

Robert A Duff wrote:
> 
> Darren New <dnew@san.rr.com> writes:
> 
> > Robert A Duff wrote:
> > > If you're running under a proper operating system, then all resources
> > > visible outside the program will be cleaned up when the program exits.
> >
> > This is true only in the most trivial sense. If I have a program that
> > contacts a license manager (for example) and grabs the license, then aborts,
> > I could be in trouble. That's why license managers check for that sort of
> > failure.
> 
> So if it's checked for, what's the problem?

Well, it isn't the OS doing it.

> The OS has to recover from those nasties
> without leaking resources. 

It doesn't recover from those nasties without leaking resources.

> So surely calling "exit" is no worse.

Correct. I'm not arguing that you shouldn't have "exit". I'm merely saying
that "the OS cleans up all externally-visible resources" is an
oversimplification.
 
> I don't know Amiga, but it seems to me that if a crashed program causes
> memory leaks, the OS is broken.

No more than "a crashed program might leave half-written temp files around"
is "broken".
 
> > So no, in general, a "proper" operating system doesn't clean up all visible
> > resources. Not even with exit() calls. :-)
> 
> I guess it depends on what "proper" OS means.  I'm assuming hardware
> memory protection, and an OS that takes advantage of that to reclaim
> resources from crashed processes.

I think it more depends on what you mean by "resources". I've worked on OSes
where you had "temp files" that went away when you logged out. UNIX doesn't
have that. Are junk-files in /tmp a "resource leak" the OS should clean up?

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
   ** http://images.fbrtech.com/dnew/ **

Try our EbolaBurgers...
      So tender they melt in your mouth.

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

[Robert A Duff]

Darren New <dnew@san.rr.com> writes:

> Robert A Duff wrote:
> > 
> > Darren New <dnew@san.rr.com> writes:
> > 
> > > Robert A Duff wrote:
> > > > If you're running under a proper operating system, then all resources
> > > > visible outside the program will be cleaned up when the program exits.
> > >
> > > This is true only in the most trivial sense. If I have a program that
> > > contacts a license manager (for example) and grabs the license, then aborts,
> > > I could be in trouble. That's why license managers check for that sort of
> > > failure.
> > 
> > So if it's checked for, what's the problem?
> 
> Well, it isn't the OS doing it.

OK, I admit, I was oversimplifying.

Still, if the OS allocates some physical memory to a process, and the
process dies, the OS ought to reclaim that memory.  If a license manager
allocates a license to a process, and the process dies, the license
manager ought to reclaim it.  If an airline terminal crashes in the
middle of allocating a seat, the seat should not be permanently empty on
all further flights.

My point is simply that "exit" shouldn't be any worse than a crash.

And that we can't rely on Ada finalization for those sorts of cleanup.

> > The OS has to recover from those nasties
> > without leaking resources. 
> 
> It doesn't recover from those nasties without leaking resources.
> 
> > So surely calling "exit" is no worse.
> 
> Correct. I'm not arguing that you shouldn't have "exit". I'm merely saying
> that "the OS cleans up all externally-visible resources" is an
> oversimplification.

Agreed.

> > I don't know Amiga, but it seems to me that if a crashed program causes
> > memory leaks, the OS is broken.
> 
> No more than "a crashed program might leave half-written temp files around"
> is "broken".

I suppose, if somebody can clean up that memory without rebooting.

> > > So no, in general, a "proper" operating system doesn't clean up all visible
> > > resources. Not even with exit() calls. :-)
> > 
> > I guess it depends on what "proper" OS means.  I'm assuming hardware
> > memory protection, and an OS that takes advantage of that to reclaim
> > resources from crashed processes.
> 
> I think it more depends on what you mean by "resources". I've worked on OSes
> where you had "temp files" that went away when you logged out. UNIX doesn't
> have that. Are junk-files in /tmp a "resource leak" the OS should clean up?

I don't know.  I suppose Unix is broken in that regard.  I must admit
that I've had to delete "by hand" some junk in /tmp, which rogue
programs left lying around.

- Bob

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

[Marin D. Condic]

Yes, I understand that there are potential issues as to what exactly happens
from one OS to another and I understand that there are dangers in its use
because its behavior can't necessarily deal with everything cleanly or do
what you would want it to do under the circumstances. But note that a)
Windows does provide an OS call to abort the process and b) I said the
following:

> > Would the formal definition need to be any more complicated than:
> > "Implementation Defined - but we suggest that you make it do what any
sane
> > person using the target OS would reasonably expect..."? It doesn't seem

(In other words, you could have it make monkeys fly out of your nose, but a
sane person would expect it to call the OS provided "abort" procedure and do
whatever that does.)

Just because there is no absolutely safe or absolutely portable or
absolutely consistent way of doing something in Ada, doesn't mean it
shouldn't be done. A complaint that a lot of C programmers have about Ada is
that it keeps stoping them from doing what they want to do. Sometimes that
is a good thing, but sometimes its just plain stubbornness on the part of
Ada insisting that because an answer isn't "perfect" that it won't provide
one that is "good enough". Providing a portable interface to what ANSI C
calls "abort();" (and similar...) doesn't sound like something that should
be avoided just because it might be misused or that the results might not be
consistent across all platforms.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com

Enabling Digital.
Our Vision is to be the biggest supplier worldwide of digital gateway
technology.
www.pacemicro.com

"Dmitry A.Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:akkrtr$1jg0vq$1@ID-77047.news.dfncis.de...

>
> Consider Windows. To kill a process, does not mean that all DLLs and all
> non-standard drivers it used get notified. Which also means that even if
> you have killed a process the system is not brought to the state it had
> before the process start. Yes, you can define a procedure Kill_The_Process
> but you cannot specifiy what this procedure does! Which resources will be
> freed? Will they available after procedure completion? What about access
> rights? So the single thing which will be portable is the name of the
> procedure. (:-))
>

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

[Robert A Duff]

Dmitry A.Kazakov <mailbox@dmitry-kazakov.de> writes:

> Robert A Duff wrote:
> 
> > Dmitry A.Kazakov <mailbox@dmitry-kazakov.de> writes:
> > 
> >> For example? Abort without any defined clean-up warranties absolutely
> >> nothing.
> >> 
> >> Otherwise, some sort of "finalization" should be defined. For instance:
> >> known tasks killed, known memory returned. But (1) any sort of
> >> finalization could still hang up.
> > 
> > If you're running under a proper operating system, then all resources
> > visible outside the program will be cleaned up when the program exits.
> > Therefore, there is no need for finalization to clean up such resources.
> > (I'm talking about the Ada finalization here.) 
> 
> But cleaning up the resources *is* a finalization.

You can call it "finalization" if you like, but it's not Ada finalization.

>... When a file is closed, 
> some code has to be executed [no matter on which context]. So there is no 
> difference in that respect between how Ada and how an OS does it. 

There is a huge difference: Ada finalization takes place inside the
process, and a broken Ada program can cause finalization to not work.
Cleanup performed by the OS happens in the OS, and cannot be damaged
by anything the Ada program does, including using unchecked conversion
of pointers to scribble all over the address space.  Even a bug in the
Ada compiler cannot damage the OS.

As before, I'm only talking about a "proper" OS, which uses hardware
memory protection to ensure security of OS data structures.  (Of course
if the OS has bugs, all bets are off.)

The point is that you can count on the OS to (for example) close open
file handles when the process exits.  You cannot count on Ada
finalization to do that.

>...The 
> actual difference is that Ada precisely specifies what "task abort" means.
> 
> > Certainly, "exit" will
> > kill all tasks in the program and recover all memory.  There is no need
> > for finalization to clean up resources internal to the program, either
> > -- the program is about to vanish.
> 
> No OS can warranty that *all* external resources will be freed. 

Well, OK, I admit I overstated my case.  Nonetheless, if you know what
external resources your program uses, and you are running under a proper
OS, then you can deal with these issues.

> That's clear, but what kind of external finalization has to be performed? 
> Because you cannot warranty that *all* external resources will be freed, 
> you should specify which ones will be.

It's not the job of the Ada RM to talk about what happens outside the
Ada program.

>... It is possible, but IMO very 
> difficult. Alternatively, you can say that it warranties nothing. Then 
> well, the external *portable* effect = "does nothing". Who might need that 
> thing?

The Ada RM warrants nothing, but that's OK -- look it up in your OS
manual.

None of this has anything to do with calling "exit" prematurely.  All
these horrible things and lack of warranties you mention are true when
an Ada program exits normally (by getting to the end of the program in
the usual way).  If you run this simple program:

    procedure Main is
    begin
        null;
    end Main;

there is no guarantee in the Ada RM that the OS won't leak memory,
or forget to close the stdout file handle, etc.  Creating a new feature
like "exit()" would not make things any worse.  It's not Ada's job to
talk about what the OS ought to do.

- Bob

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

[Robert A Duff]

Kilgallen@SpamCop.net (Larry Kilgallen) writes:

> In article <akin0p$fma$1@nh.pace.co.uk>, "Marin D. Condic" <not.valid@acm.org> writes:
> 
> > There can't be *that* many different ways of killing the process that a
> > reasonable compromise answer couldn't be found. What more would be needed
> > than a "Kill_The_Process (Optional_Integer_Return_Code_For_Unix_Freaks) ;"
> > call? Would it need to be dramatically different between Unix/Windows/Mac?
> > Would anyone care if it couldn't be implemented easily on some obscure OS?
> 
> As I recall, you had some VMS background, so VMS is not "obscure" :-)
> 
> 	1. With what error code should one exit (odd numbers mean success) ?

This question is answered (as well as it can be) by the Ada.Command_Line
package.  Of course, there is no completely portable answer, but that
didn't prevent this useful package from being standardized.

> 	2. Do you want to run exit handlers in the executable image
> 	   and the various shareable images it invoked ?
> 	3. Do you want to run exit handling in the batch file that
> 	   is controlling the program ?

The obvious answer is "implementation dependent".  The Ada RM has no
business talking about VMS-specific features.

Note that these questions arise even for programs that exit normally.
The Ada RM doesn't address them.  The Ada implementer must choose
a sensible answer (like, "Yes, exit handlers are run.").

> But you cannot avoid running the exit handlers associated with a
> privileged shareable image.  It is possible to construct a pathelogical
> case that will not kill the process since that would damage system
> integrity.

Consider this analogy: You can use Ada.Text_IO to write a file.  The Ada
RM says nothing about what happens to that file after the program is
done.  (For example, there's no guarantee that another Ada program can
read that file back in.  If the "file" is really the screen, then the
data will quickly vanish!)  But that doesn't mean that Ada can't define
I/O packages -- it just means that part of their useful semantics is
outside the universe considered by the Ada RM.  The same is true for
"exit", or any other feature that interfaces to the world outside the
Ada program.

Do you avoid writing programs that do I/O, because I/O is inherently
non-portable?  ;-)

- Bob

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

[Dennis Lee Bieber]

Robert A Duff fed this fish to the penguins on Wednesday 28 August 2002 
03:22 pm:

> Darren New <dnew@san.rr.com> writes:
> 
>> Other OSes (like Amiga's OS) specifically don't clean up anything at
>> all, as this lets you do things like allocate memory, load a program
>> into it, and start it up and then exit yourself. You have to clean it
>> up for yourself.
> 
> I don't know Amiga, but it seems to me that if a crashed program
> causes memory leaks, the OS is broken.
>
        The described behavior is closer to a VMS spawn (or fork() call). 
Essentially the initial program has done the memory allocation/image 
load, after which the new process is totally independent (hence 
responsible for it's own process termination cleanup).

        One caveat, the Amiga OS did not natively handle virtual/protected 
memory -- it used a single global address space (it ran on 68000 
processors). There were modules to make use of virtual addressing on 
later processors, but still no protected memory. OTOH, we are talking a 
system with a multi-priority round-robin preemptive task scheduler that 
ran off 880K floppies with a graphical (the "text" interface required 
the graphical libraries just to render text) interface in 256K RAM -- 
this, when M$ Windows was around the 3.0 (or earlier) where the window 
manager handled task swapping on top of a non-multitasked base.
 
-- 
--
 > ============================================================== <
 >   wlfraed@ix.netcom.com  | Wulfraed  Dennis Lee Bieber  KD6MOG <
 >      wulfraed@dm.net     |       Bestiaria Support Staff       <
 > ============================================================== <
 >        Bestiaria Home Page: http://www.beastie.dm.net/         <
 >            Home Page: http://www.dm.net/~wulfraed/             <

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

[Warren W. Gay VE3WWG]

Robert A Duff wrote:
> Darren New <dnew@san.rr.com> writes:
>>Robert A Duff wrote:
>>>Darren New <dnew@san.rr.com> writes:
>>>>Robert A Duff wrote:
>>>>
>>>>>If you're running under a proper operating system, then all resources
>>>>>visible outside the program will be cleaned up when the program exits.
>>>>
>>>>This is true only in the most trivial sense. If I have a program that
>>>>contacts a license manager (for example) and grabs the license, then aborts,
>>>>I could be in trouble. That's why license managers check for that sort of
>>>>failure.
>>>
>>>So if it's checked for, what's the problem?
>>
>>Well, it isn't the OS doing it.
> 
> OK, I admit, I was oversimplifying.
> 
> Still, if the OS allocates some physical memory to a process, and the
> process dies, the OS ought to reclaim that memory.  If a license manager
> allocates a license to a process, and the process dies, the license
> manager ought to reclaim it.  ...

Even in "proper O/S" there are occaisions where cleanup is needed,
but not automatically done by the O/S. Here are 3 examples of
this, that can happen on [pick your] UNIX:

   - Allocated _SHARED_ memory
   - Created message queues (IPC)
   - Create semaphores

The reason these are not automatically cleaned up by the O/S is that
sometimes you want them to persist beyond the creating process'
lifetime (because they are shared by other processes).

However, you may also not want those resources to exist upon the
process termination -- this depends upon the application, or process
involved.

> My point is simply that "exit" shouldn't be any worse than a crash.

It can be, just see the above. It can leave unwanted IPC resources
hanging around, and even worse, in an indeterminant state (for shared
memory region could be left partially updated).

Also, if exit is called with threads (tasks) involved, and this
is invoked in an uncoordinated way, the "cleanup code" itself
can barf all over the place leading to things like high CPU usage
loops (hanging process), core file or spewing output etc., because
now you are expecting cleanup code to cleanup with "indefined state"
data.

> And that we can't rely on Ada finalization for those sorts of cleanup.

Especially in the context of "safe programming" practices.

>>I think it more depends on what you mean by "resources". I've worked on OSes
>>where you had "temp files" that went away when you logged out. UNIX doesn't
>>have that. Are junk-files in /tmp a "resource leak" the OS should clean up?
> 
> I don't know.  I suppose Unix is broken in that regard.  I must admit
> that I've had to delete "by hand" some junk in /tmp, which rogue
> programs left lying around.
> 
> - Bob

This depends upon the application designer (not the O/S). The temp file
is indeed automatically cleaned up by the O/S if the application writer
uses the correct calls or does it correctly himself. If you truly want
the file to cleanup itself, open(2) it, unlink(2) it, and the file will
automatically be cleaned up when the file is close(2) (voluntarily
by the application or by the O/S when the process is terminated, even
in the kill -9 or abort case).

The point is that the O/S is not broken in this regard ;-)

Many people rely on the atexit() processing, which is like
finalization -- you cannot always count on it in an abort-like
termination of the program (definitely not, when kill -9 is
involved). But don't blame the O/S for this. This type of
cleanup is voluntary application cleanup -- only that the
app usually depends upon library routines to do it.

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

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

[Warren W. Gay VE3WWG]

Dmitry A.Kazakov wrote:
> Robert A Duff wrote:
>>Dmitry A.Kazakov <mailbox@dmitry-kazakov.de> writes:
>>>Robert A Duff wrote:
>>>>Dmitry A.Kazakov <mailbox@dmitry-kazakov.de> writes:
...
> It is true, but I am afraid that future OS's will be even less reliable in 
> that respect than current ones. Consider an OO OS with no files, no 
> external memory, but only persistent objects allocated remotely etc. It 
> could be hard to tie processes such objects.

I don't think that this is much different from various
files on different NFS mounts from being closed
prematurely, or with botched updates.

The technical management may vary, but the problem already
exists today.

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

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

[Warren W. Gay VE3WWG]

Dmitry A.Kazakov wrote:
> Marin D. Condic wrote:
>>Oh, and how could it be defined in a portable way? C does it with a couple
>>of standard functions. Ada can make standard subprograms too, so why not?
>>Probably (since it is an OS dependent thing and might not have meaning
>>outside the context of an OS) there should be some sort of standard
>>package like "Ada.OS_Services" that contained proccedure(s) to connect to
>>whatever the OS provides. (I hear something like this is in the works)
>>
>>There can't be *that* many different ways of killing the process that a
>>reasonable compromise answer couldn't be found. What more would be needed
>>than a "Kill_The_Process (Optional_Integer_Return_Code_For_Unix_Freaks) ;"
>>call? Would it need to be dramatically different between Unix/Windows/Mac?
>>Would anyone care if it couldn't be implemented easily on some obscure OS?
>>Would the formal definition need to be any more complicated than:
>>"Implementation Defined - but we suggest that you make it do what any sane
>>person using the target OS would reasonably expect..."? It doesn't seem
>>like Rocket Science to me - nor does it sound like a horendous burden on
>>the compiler writers. The only real question could be "Is it reasonably
>>useful to have such an operation?" and I think the answer is "Yes".
> 
> Consider Windows. To kill a process, does not mean that all DLLs and all 
> non-standard drivers it used get notified. Which also means that even if 
> you have killed a process the system is not brought to the state it had 
> before the process start. Yes, you can define a procedure Kill_The_Process 
> but you cannot specifiy what this procedure does! Which resources will be 
> freed? Will they available after procedure completion? What about access 
> rights? So the single thing which will be portable is the name of the 
> procedure. (:-))

The other question that comes up with COM objects is whether or not
the object should be "unreferenced". But if you do allow the unref
call, then other code may run that may experience "difficulties".
The UNIX equivalent of a kill -9 in windows would leave many COM
objects referenced after the processes are gone. Yuk. I smell another
reboot coming on ;-)

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

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

[Marin D. Condic]

But thats what Windows *does* when you kill a process. Is that an Ada
problem or a Windows problem? What if the Ada program crashed? Would we say
that the Ada standard should not permit crashes because the effects on the
OS are not portable or may be unreliable? :-) (Boy, we'd really have the
C/C++ guys on the ropes! "Its against the ARM for an Ada program to crash,
so if it does, blame your compiler vendor..." :-)

Sure, maybe Windows is an example of rebootive multitasking, but if someone
develops on top of Windows, its their design choice and they have to live
with the limitations. If Ada had its own flavor of "abort();" under Windows
it would be no more dangerous than C or C++ in that regard.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com

Enabling Digital.
Our Vision is to be the biggest supplier worldwide of digital gateway
technology.
www.pacemicro.com

"Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> wrote in message
news:3D6E52EF.2010406@cogeco.ca...
>
> The other question that comes up with COM objects is whether or not
> the object should be "unreferenced". But if you do allow the unref
> call, then other code may run that may experience "difficulties".
> The UNIX equivalent of a kill -9 in windows would leave many COM
> objects referenced after the processes are gone. Yuk. I smell another
> reboot coming on ;-)
>

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

[Larry Kilgallen]

In article <3D6E507E.7010805@cogeco.ca>, "Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> writes:

> Even in "proper O/S" there are occaisions where cleanup is needed,
> but not automatically done by the O/S. Here are 3 examples of
> this, that can happen on [pick your] UNIX:
> 
>    - Allocated _SHARED_ memory
>    - Created message queues (IPC)
>    - Create semaphores
> 
> The reason these are not automatically cleaned up by the O/S is that
> sometimes you want them to persist beyond the creating process'
> lifetime (because they are shared by other processes).

VMS tends toward making those go away when the last accessing program
exists.  At least for the first one there is an option to make it really
permanent, but I don't think I have ever really wanted that.

> This depends upon the application designer (not the O/S). The temp file
> is indeed automatically cleaned up by the O/S if the application writer
> uses the correct calls or does it correctly himself.

On top of all those other requirements, you want correct programming ?

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

[Robert C. Leif]

From: Bob Leif
To: The readers of Comp.Lang.Ada
We have been witness to an extended discourse on this subject. Although,
it appears that there may not be an utterly reliable solution to this
problem, it is quite evident that even an imperfect solution would be
better than none. Since as an Ada user I know that the Ada compiler
vendor's technical knowledge is better than my own, I would prefer that
the vendor supplies their best effort; and that the call to this
ubiquitous routine be standardized. 

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

[Warren W. Gay VE3WWG]

Larry Kilgallen wrote:
> In article <3D6E507E.7010805@cogeco.ca>, "Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> writes:
> 
> 
>>Even in "proper O/S" there are occaisions where cleanup is needed,
>>but not automatically done by the O/S. Here are 3 examples of
>>this, that can happen on [pick your] UNIX:
>>
>>   - Allocated _SHARED_ memory
>>   - Created message queues (IPC)
>>   - Create semaphores
>>
>>The reason these are not automatically cleaned up by the O/S is that
>>sometimes you want them to persist beyond the creating process'
>>lifetime (because they are shared by other processes).
> 
> VMS tends toward making those go away when the last accessing program
> exists.  At least for the first one there is an option to make it really
> permanent, but I don't think I have ever really wanted that.

UNIX does support the idea of a SEM_UNDO operation, where semaphores
are "undone" if the process is blown away. However, even that is
not necessarily the right thing to do (do you want to unlock a botched
shared memory region and hope for the best?)

>>This depends upon the application designer (not the O/S). The temp file
>>is indeed automatically cleaned up by the O/S if the application writer
>>uses the correct calls or does it correctly himself.
> 
> On top of all those other requirements, you want correct programming ?

Is there any other kind of Ada programmer? ;-)

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

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

[Warren W. Gay VE3WWG]

Robert C. Leif wrote:
> From: Bob Leif
> To: The readers of Comp.Lang.Ada
> We have been witness to an extended discourse on this subject. Although,
> it appears that there may not be an utterly reliable solution to this
> problem, it is quite evident that even an imperfect solution would be
> better than none. Since as an Ada user I know that the Ada compiler
> vendor's technical knowledge is better than my own, I would prefer that
> the vendor supplies their best effort; and that the call to this
> ubiquitous routine be standardized. 

The vendor would have some issue with this however -- when
his phone starts ringing with complaining customers about
why this "feature" doesn't always work, and that the
vendor "should fix this piece of _____, that he paid x bucks for"
blah blah blah.

The best you can hope for here IMHO, is that the application writer
should know both his application and the platform(s) of deployment.
-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

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

[Robert A Duff]

"Marin D. Condic" <not.valid@acm.org> writes:

> Just because there is no absolutely safe or absolutely portable or
> absolutely consistent way of doing something in Ada, doesn't mean it
> shouldn't be done. A complaint that a lot of C programmers have about Ada is
> that it keeps stoping them from doing what they want to do. Sometimes that
> is a good thing, but sometimes its just plain stubbornness on the part of
> Ada insisting that because an answer isn't "perfect" that it won't provide
> one that is "good enough". Providing a portable interface to what ANSI C
> calls "abort();" (and similar...) doesn't sound like something that should
> be avoided just because it might be misused or that the results might not be
> consistent across all platforms.

I very much agree with that.  This kind of reasoning is how we got
things like Ada.Command_Line and Get_Immediate into the language.
Sure, they're not 100% portable -- they can't be, because they interface
with the outside world.

But in this case, I can't get too excited about a "standard" version.
Why not pragma-Import "exit" or "abort", and use that?  That's portable
enough, in practise.  I have done this (knowing full well what resources
my program is meddling with), and gotten it working just fine, with the
identical code working on Solaris, Linux, and Windows.  It might not
work on some embedded board, but this particular program was not an
embedded program.  It also uses sockets, for example, which I don't
expect to be available in the chip that controls a toaster or an
airplane.

- Bob

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

[Robert A Duff]

Kilgallen@SpamCop.net (Larry Kilgallen) writes:

> In article <mailman.1030647842.10008.comp.lang.ada@ada.eu.org>, "Robert C. Leif" <rleif@rleif.com> writes:
> 
> > From: Bob Leif
> > To: The readers of Comp.Lang.Ada
> 
> Please drop those little headers.  Thanks.

:-) :-) :-) 

We all have our little quirks. :-)

> > We have been witness to an extended discourse on this subject. Although,
> > it appears that there may not be an utterly reliable solution to this
> > problem, it is quite evident that even an imperfect solution would be
> > better than none.
> 
> That is not evident to me.  If I know I have to use a system specific
> technique, I will take care to study the problem.  If Ada provides it,
> I expect it to be robust without me peeking into the innards.

So you should make sure all your Ada programs loop forever, so you never
have to deal with those nasty OS issues of what happens when the program
exits.  ;-)

Ada does have this "feature" that when the program gets done it's done.
And then it exits into the never-never land of the OS.  One wonders what
happens to all the files it wrote upon, and all the shared memory
partitions it created.

- Bob

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

[Larry Kilgallen]

In article <mailman.1030647842.10008.comp.lang.ada@ada.eu.org>, "Robert C. Leif" <rleif@rleif.com> writes:

> From: Bob Leif
> To: The readers of Comp.Lang.Ada

Please drop those little headers.  Thanks.

> We have been witness to an extended discourse on this subject. Although,
> it appears that there may not be an utterly reliable solution to this
> problem, it is quite evident that even an imperfect solution would be
> better than none.

That is not evident to me.  If I know I have to use a system specific
technique, I will take care to study the problem.  If Ada provides it,
I expect it to be robust without me peeking into the innards.

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

[Dmitry A.Kazakov]

Marin D. Condic wrote:

> Oh, and how could it be defined in a portable way? C does it with a couple
> of standard functions. Ada can make standard subprograms too, so why not?
> Probably (since it is an OS dependent thing and might not have meaning
> outside the context of an OS) there should be some sort of standard
> package like "Ada.OS_Services" that contained proccedure(s) to connect to
> whatever the OS provides. (I hear something like this is in the works)
> 
> There can't be *that* many different ways of killing the process that a
> reasonable compromise answer couldn't be found. What more would be needed
> than a "Kill_The_Process (Optional_Integer_Return_Code_For_Unix_Freaks) ;"
> call? Would it need to be dramatically different between Unix/Windows/Mac?
> Would anyone care if it couldn't be implemented easily on some obscure OS?
> Would the formal definition need to be any more complicated than:
> "Implementation Defined - but we suggest that you make it do what any sane
> person using the target OS would reasonably expect..."? It doesn't seem
> like Rocket Science to me - nor does it sound like a horendous burden on
> the compiler writers. The only real question could be "Is it reasonably
> useful to have such an operation?" and I think the answer is "Yes".

Consider Windows. To kill a process, does not mean that all DLLs and all 
non-standard drivers it used get notified. Which also means that even if 
you have killed a process the system is not brought to the state it had 
before the process start. Yes, you can define a procedure Kill_The_Process 
but you cannot specifiy what this procedure does! Which resources will be 
freed? Will they available after procedure completion? What about access 
rights? So the single thing which will be portable is the name of the 
procedure. (:-))

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

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

[Dmitry A.Kazakov]

Robert A Duff wrote:

> Dmitry A.Kazakov <mailbox@dmitry-kazakov.de> writes:
> 
>> For example? Abort without any defined clean-up warranties absolutely
>> nothing.
>> 
>> Otherwise, some sort of "finalization" should be defined. For instance:
>> known tasks killed, known memory returned. But (1) any sort of
>> finalization could still hang up.
> 
> If you're running under a proper operating system, then all resources
> visible outside the program will be cleaned up when the program exits.
> Therefore, there is no need for finalization to clean up such resources.
> (I'm talking about the Ada finalization here.) 

But cleaning up the resources *is* a finalization. When a file is closed, 
some code has to be executed [no matter on which context]. So there is no 
difference in that respect between how Ada and how an OS does it. The 
actual difference is that Ada precisely specifies what "task abort" means.

> Certainly, "exit" will
> kill all tasks in the program and recover all memory.  There is no need
> for finalization to clean up resources internal to the program, either
> -- the program is about to vanish.

No OS can warranty that *all* external resources will be freed. The margin 
is very unsharf. What if the process starts some system service? Is that an 
external resource?

> *Some* kinds of finalization might be broken by "exit".  For example, if
> some Finalize routine flushes a buffer to disk, and you want that buffer
> flushed.  So you can't blithely call "exit" without some global
> knowledge of how finalization is used in your program.
> 
> If you're not using an operating system then the story is very
> different.
> 
>>... (2) How to define it in a portable way (= in language
>> terms)?
> 
> Seems pretty straightforward to me.  Just define a feature that halts
> the program and doesn't run any finalization. 

That's clear, but what kind of external finalization has to be performed? 
Because you cannot warranty that *all* external resources will be freed, 
you should specify which ones will be. It is possible, but IMO very 
difficult. Alternatively, you can say that it warranties nothing. Then 
well, the external *portable* effect = "does nothing". Who might need that 
thing?

> In an embedded system,
> the appropriate implementation might be:
> 
>     <<Self>> goto Self;

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

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

[Dmitry A.Kazakov]

Robert A Duff wrote:

> Dmitry A.Kazakov <mailbox@dmitry-kazakov.de> writes:
> 
>> Robert A Duff wrote:
>> 
>> > Dmitry A.Kazakov <mailbox@dmitry-kazakov.de> writes:
>> > 
>> >> For example? Abort without any defined clean-up warranties absolutely
>> >> nothing.
>> >> 
>> >> Otherwise, some sort of "finalization" should be defined. For
>> >> instance: known tasks killed, known memory returned. But (1) any sort
>> >> of finalization could still hang up.
>> > 
>> > If you're running under a proper operating system, then all resources
>> > visible outside the program will be cleaned up when the program exits.
>> > Therefore, there is no need for finalization to clean up such
>> > resources. (I'm talking about the Ada finalization here.)
>> 
>> But cleaning up the resources *is* a finalization.
> 
> You can call it "finalization" if you like, but it's not Ada finalization.

Even if OS is written in Ada? (:-)) But yes I did not mean an Ada 
finalization here.

>>... When a file is closed,
>> some code has to be executed [no matter on which context]. So there is no
>> difference in that respect between how Ada and how an OS does it.
> 
> There is a huge difference: Ada finalization takes place inside the
> process, and a broken Ada program can cause finalization to not work.

You mean a context here. A good built software should have several [more 
than two - user process and kernel] contexts. But anyway an exception in a 
nested context may cause finalization of some objects external to the 
nested context. There is no difference in how such an object is destroyed 
when you leave a block and how files are closed after killing a process.

> Cleanup performed by the OS happens in the OS, and cannot be damaged
> by anything the Ada program does, including using unchecked conversion
> of pointers to scribble all over the address space.  Even a bug in the
> Ada compiler cannot damage the OS.

Technically it is an implementation detail. One could achieve a similar 
effect in Ada by a consequent allocation all objects in separated storage 
pools local to the blocks you want to be "user-contexts". When block "dies" 
all memory is reclaimed. It can be made hardware-supported. I would prefer 
to see some language mechanism to enforce that sort of memory allocation, 
than try to interface an unknown OS.

> As before, I'm only talking about a "proper" OS, which uses hardware
> memory protection to ensure security of OS data structures.  (Of course
> if the OS has bugs, all bets are off.)
> 
> The point is that you can count on the OS to (for example) close open
> file handles when the process exits.  You cannot count on Ada
> finalization to do that.

It is true, but I am afraid that future OS's will be even less reliable in 
that respect than current ones. Consider an OO OS with no files, no 
external memory, but only persistent objects allocated remotely etc. It 
could be hard to tie processes such objects.

>>... It is possible, but IMO very
>> difficult. Alternatively, you can say that it warranties nothing. Then
>> well, the external *portable* effect = "does nothing". Who might need
>> that thing?
> 
> The Ada RM warrants nothing, but that's OK -- look it up in your OS
> manual.
> 
> None of this has anything to do with calling "exit" prematurely.  All
> these horrible things and lack of warranties you mention are true when
> an Ada program exits normally (by getting to the end of the program in
> the usual way).  If you run this simple program:
> 
>     procedure Main is
>     begin
>         null;
>     end Main;
> 
> there is no guarantee in the Ada RM that the OS won't leak memory,
> or forget to close the stdout file handle, etc.

Because the Universe (OS) ceases to exist with the death of an Ada program! 
It is an absolutely perfect solipsistic point of view as long as you do 
not refer OS in ARM. (:-)) 

> Creating a new feature
> like "exit()" would not make things any worse.

Doing this you would become a materialist with an imminent obligation to 
explain how the Universe (OS) works. (:-))

> It's not Ada's job to
> talk about what the OS ought to do.

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

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

[Ole-Hjalmar Kristensen]

"Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> writes:

> Robert A Duff wrote:
> > Darren New <dnew@san.rr.com> writes:
> >>Robert A Duff wrote:
> >>>Darren New <dnew@san.rr.com> writes:
> >>>>Robert A Duff wrote:
> >>>>
> >>>>>If you're running under a proper operating system, then all resources
> >>>>>visible outside the program will be cleaned up when the program exits.
> >>>>
> >>>>This is true only in the most trivial sense. If I have a program that
> >>>>contacts a license manager (for example) and grabs the license, then aborts,
> >>>>I could be in trouble. That's why license managers check for that sort of
> >>>>failure.
> >>>
> >>>So if it's checked for, what's the problem?
> >>
> >>Well, it isn't the OS doing it.
> > OK, I admit, I was oversimplifying.
> > Still, if the OS allocates some physical memory to a process, and the
> > process dies, the OS ought to reclaim that memory.  If a license manager
> > allocates a license to a process, and the process dies, the license
> > manager ought to reclaim it.  ...
> 
> Even in "proper O/S" there are occaisions where cleanup is needed,
> but not automatically done by the O/S. Here are 3 examples of
> this, that can happen on [pick your] UNIX:
> 
>    - Allocated _SHARED_ memory
>    - Created message queues (IPC)
>    - Create semaphores
> 
> The reason these are not automatically cleaned up by the O/S is that
> sometimes you want them to persist beyond the creating process'
> lifetime (because they are shared by other processes).
> 

Certainly, it can cause a leak, but the leak does not get bigger when
you run the program again, because as you point out, you can aquire
the same resource again, and it's pretty trivial to check for the
existence of those *named* objects on startup. Contrast this with an
OS which leaks memory, does not close file handles, etc. On the next
run of the program, you will probably aquire a *new* chunk of memory
or another file handle, and so the garbage will build up over time.

<snip>

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

[Simon Wright]

Robert A Duff <bobduff@shell01.TheWorld.com> writes:

> Ada does have this "feature" that when the program gets done it's
> done.  And then it exits into the never-never land of the OS.  One
> wonders what happens to all the files it wrote upon, and all the
> shared memory partitions it created.

Just as if you do the same in C, surely!

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

[Toshitaka Kumano]

"Dmitry A.Kazakov" wrote:
> Well, if so little is required then Annex B is a perfect place for this:
> 
(snip)
> Interfaces.Win32

That will make annual amendments of the ISO standard ?
:-)

-- 
Toshitaka Kumano
Kamakura, Japan

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

[Dmitry A.Kazakov]

Marin D. Condic wrote:

> Yes, I understand that there are potential issues as to what exactly
> happens from one OS to another and I understand that there are dangers in
> its use because its behavior can't necessarily deal with everything
> cleanly or do what you would want it to do under the circumstances. But
> note that a) Windows does provide an OS call to abort the process

They (MS) wrote the following about it:

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

> and b) I said the following:

>> > Would the formal definition need to be any more complicated than:
>> > "Implementation Defined - but we suggest that you make it do what any
>> > sane person using the target OS would reasonably expect..."? It
>> > doesn't seem

> (In other words, you could have it make monkeys fly out of your nose, but
> a sane person would expect it to call the OS provided "abort" procedure
> and do whatever that does.)

I have only one objection - this cannot be called "portable". There is also 
a problem, where do you want to stop? Portable sockets? Pipes? Mailboxes? 
FTP? 2D-graphics? 3D? SQL? ...

Not that I am against all that (:-)), but it will be very hard to do.

> Just because there is no absolutely safe or absolutely portable or
> absolutely consistent way of doing something in Ada, doesn't mean it
> shouldn't be done. A complaint that a lot of C programmers have about Ada
> is that it keeps stoping them from doing what they want to do. Sometimes
> that is a good thing, but sometimes its just plain stubbornness on the
> part of Ada insisting that because an answer isn't "perfect" that it won't
> provide one that is "good enough". Providing a portable interface to what
> ANSI C calls "abort();" (and similar...) doesn't sound like something that
> should be avoided just because it might be misused or that the results
> might not be consistent across all platforms.

Well, if so little is required then Annex B is a perfect place for this:

Interfaces.POSIX
Interfaces.VMS
Interfaces.Win32
...

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

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

[Warren W. Gay VE3WWG]

Ole-Hjalmar Kristensen wrote:
> "Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> writes:
>>Robert A Duff wrote:
>>>Darren New <dnew@san.rr.com> writes:
>>>>Robert A Duff wrote:
>>>>>Darren New <dnew@san.rr.com> writes:
>>>>>>Robert A Duff wrote:
...
>>Even in "proper O/S" there are occaisions where cleanup is needed,
>>but not automatically done by the O/S. Here are 3 examples of
>>this, that can happen on [pick your] UNIX:
>>
>>   - Allocated _SHARED_ memory
>>   - Created message queues (IPC)
>>   - Create semaphores
>>
>>The reason these are not automatically cleaned up by the O/S is that
>>sometimes you want them to persist beyond the creating process'
>>lifetime (because they are shared by other processes).
> 
> Certainly, it can cause a leak, but the leak does not get bigger when
> you run the program again, because as you point out, you can aquire
> the same resource again, and it's pretty trivial to check for the
> existence of those *named* objects on startup. 

This is only true, if the application has arranged to make the
resource globally identifiable, or has saved the IPC ID. A group
of cooperating processes often only creates the necessary IPC
resources and only knows them by IPC ID (for example, the
resources are created, and a few subsequent fork(2) calls
are made to share the resource known by IPC ID). After an abort,
the IPC IDs are no longer known to the application -- and will create
a new resource set instead. So this really depends upon the
application design.  THIS IS NOT A "GIVEN".

> Contrast this with an
> OS which leaks memory, does not close file handles, etc. On the next
> run of the program, you will probably aquire a *new* chunk of memory
> or another file handle, and so the garbage will build up over time.

The very same can and often does happen with IPC resources. Not
every application expects to re-use those resources after a
process abort.

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

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

[Dmitry A.Kazakov]

Toshitaka Kumano wrote:

> "Dmitry A.Kazakov" wrote:
>> Well, if so little is required then Annex B is a perfect place for this:
>> 
> (snip)
>> Interfaces.Win32
> 
> That will make annual amendments of the ISO standard ?
> :-)

Win64 comes!  (:-))

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