exit a program

exit a program

[Autoscontro difettoso]

is there an instruction that stops a program?
i need to stop a program and return to o.s. in case of an exception.

-- 

questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news segnala gli abusi ad abuse@newsland.it

Re: exit a program

[Dmitry A. Kazakov]

On Sun, 02 Aug 2009 14:13:03 +0200, Autoscontro difettoso wrote:

> is there an instruction that stops a program?

No, because it is ill-defined.

In order to define "stop of a program" consider what happens with the
system resources allocated by the program (open files, shared libraries,
sockets etc), its tasks, its objects allocated and initialized on the
stacks of the tasks and in the heap. Which of them will be freed,
finalized, deallocated etc? Once you answer these questions you could find
an appropriate way to accomplish a "stop".

> i need to stop a program and return to o.s. in case of an exception.

Let it propagate out of the main task, that will terminate the program.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: exit a program

[Robert A Duff]

asd@fdsfs.com (Autoscontro difettoso) writes:

> is there an instruction that stops a program?

In GNAT, look at GNAT.OS_Lib.  You can call OS_Exit or OS_Abort.

In other compilers, you can call "exit" or "abort" via pramga Import.

Alternatively, you can abort the environment task.  Look at
Ada.Task_Identification.  If you call Current_Task during library-level
elaboration, you can save the identity of the env task.

- Bob

Re: exit a program

[Maciej Sobczak]

On 2 Sie, 14:43, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:

> > is there an instruction that stops a program?
>
> No, because it is ill-defined.
>
> In order to define "stop of a program" consider what happens with the
> system resources allocated by the program (open files, shared libraries,
> sockets etc)

Shared libraries and sockets are out of Ada scope. If you are using
them, then you apparently already know what you are doing.

Files are in the scope and are handled (A.7/6):

"The language does not define what happens to external files after the
completion of the main program and all the library tasks"

I guess it is up to the implementation to fill this gap.
In other words, the concept of stopping the program is not ill-
defined...

> > i need to stop a program and return to o.s. in case of an exception.
>
> Let it propagate out of the main task, that will terminate the program.

and you even give instructions on how it can be done. ;-)

--
Maciej Sobczak * www.msobczak.com * www.inspirel.com

Database Access Library for Ada: www.inspirel.com/soci-ada

Re: exit a program

[Dmitry A. Kazakov]

On Mon, 3 Aug 2009 01:17:25 -0700 (PDT), Maciej Sobczak wrote:

> On 2 Sie, 14:43, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
> 
>>> is there an instruction that stops a program?
>>
>> No, because it is ill-defined.
>>
>> In order to define "stop of a program" consider what happens with the
>> system resources allocated by the program (open files, shared libraries,
>> sockets etc)
> 
> Shared libraries and sockets are out of Ada scope. If you are using
> them, then you apparently already know what you are doing.
> 
> Files are in the scope and are handled (A.7/6):
> 
> "The language does not define what happens to external files after the
> completion of the main program and all the library tasks"
> 
> I guess it is up to the implementation to fill this gap.
> In other words, the concept of stopping the program is not ill-
> defined...

An implementation should implement something defined up front.

>>> i need to stop a program and return to o.s. in case of an exception.
>>
>> Let it propagate out of the main task, that will terminate the program.
> 
> and you even give instructions on how it can be done. ;-)

No, I just give one possible way which effectively defines the semantics of
stop in language terms. Robert gave two others: a call to OS (outside Ada,
uncontrolled) and asynchronous transfer of control (dangerous in Ada).

The problem with any implementation is that it might be different from what
OP actually wants.

This is why it is ill-defined. If you are debugging the program you need
one type of stop, that freezes the current state as much as possible
avoiding snow ball effects. If you are dealing with some persistent
storage, you might want to roll back most of the side effects of program
execution. In other cases you might wish to set a digital output to high
causing a relay to break the power supply circuit of the computer. A
distributed program is a totally different world. And so on and so forth.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de