Exception Propagation

Exception Propagation

[Decker, Christian R]

I have some Ada code that is apparently raising an exception, but the
program just seems to hang and does not
report the exception as i have seen before.  It looks like the code just
hangs, but when i put an exception handler
around the suspect code the handler gets executed.
Am i missing some arguments to the gnatmake command to cause the propagation
of exceptions or do i have
arguments that is disabling the propagation?

my current arguments are:
gnatmake -gnatp -g -O4 -n32 -bargs -f

i tried taking out the -gnatp ( which i believe disables run-time checking
), but that doesn't help....

Thanks...
chris



   -**** Posted from RemarQ, http://www.remarq.com/?a ****-
 Search and Read Usenet Discussions in your Browser - FREE -

Re: Exception Propagation

[dennison]

In article <b3T63.5112$y6.2934699@WReNphoon3>,
  cdecker@snet.net (Decker, Christian R) wrote:
> I have some Ada code that is apparently raising an exception, but the
> program just seems to hang and does not
> report the exception as i have seen before.  It looks like the code
just
> hangs, but when i put an exception handler
> around the suspect code the handler gets executed.
> Am i missing some arguments to the gnatmake command to cause the
propagation
> of exceptions or do i have
> arguments that is disabling the propagation?
>
> my current arguments are:
> gnatmake -gnatp -g -O4 -n32 -bargs -f
>
> i tried taking out the -gnatp ( which i believe disables run-time
checking
> ), but that doesn't help....

That's the behavior I'd expect to see if the exception is occuring in a
task. The whole program doesn't terminate just because one task dies.

--
T.E.D.


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: Exception Propagation

[Glen]

dennison@telepath.com wrote:

> In article <b3T63.5112$y6.2934699@WReNphoon3>,
>   cdecker@snet.net (Decker, Christian R) wrote:
> > I have some Ada code that is apparently raising an exception, but the
> > program just seems to hang and does not
> > report the exception as i have seen before.  It looks like the code
> just
> > hangs, but when i put an exception handler
> > around the suspect code the handler gets executed.
>
> That's the behavior I'd expect to see if the exception is occuring in a
> task. The whole program doesn't terminate just because one task dies.

This feature has escaped me, or I have forgot  ( RM95 11.4(4) ), I've
also checked RM83 and found it to be a feature of that language edition.
I would rather the exception was propogated aleast this gives the option
of deciding whether  the program  terminates or not.

Given the RM specification, I think a mandatory "when others" task level
exception handler would be prudent.

Re: Exception Propagation

[Decker, Christian R]

OK, everyone is mis-understanding my question, and i apologize.....
I understand that when an exception is raised in a task that it is not
deterministic as to where the exception gets
propagated as far as being able to trap and handle it.

But as far as seeing text displayed in the console window indicating that an
excpetion was raised should always
occur, at least in every other Ada compiler i have used.  My problem is that
i see no text, or any other indication
that an exception is being raised.  I know there is an exception because i
tested using an explicit trap to display
the error.  I don't want random exception handles, i just want to be
notified via text in the console that an
exception has occured.

So with that does anyone know why i am not getting text messages telling me
an exception was raised?

thanks
Chris



   -**** Posted from RemarQ, http://www.remarq.com/?a ****-
 Search and Read Usenet Discussions in your Browser - FREE -

Re: Exception Propagation

[Robert Dewar]

In article <0nc73.5376$y6.3195132@WReNphoon3>,
  cdecker@snet.net (Decker, Christian R) wrote:
> OK, everyone is mis-understanding my question, and i
apologize.....
> I understand that when an exception is raised in a task that
it is not
> deterministic as to where the exception gets
> propagated as far as being able to trap and handle it.

No, that's confused, the exception is NOT propagated at all!

> But as far as seeing text displayed in the console window
> indicating that an
> excpetion was raised should always
> occur, at least in every other Ada compiler i have used.

Not unconditionally certainly. Terminating a task with an
unhandled exception is not an error, it is perfectly well
behaved Ada semantics. You cannot justify a compiler outputting
junk in some console window just because it thinks you are using
a feature of Ada which you should not be!

>  My problem is that
> i see no text, or any other indication
> that an exception is being raised.  I know there is an
> exception because i
> tested using an explicit trap to display
> the error.  I don't want random exception handles, i just want
> to be
> notified via text in the console that an
> exception has occured.

Then put a when others handler in your task at the outer level,
dumping the exception information. Your compiler *may* have a
special non-standard non-RM mode in which it treats this
situation as an error, or dumps stuff to some window, but there
is no requirement (or even suggestion) in the RM that such
behavior is desirable, let alone required.

> So with that does anyone know why i am not getting text
> messages telling me an exception was raised?

Because the exception was not unhandled, there is no such
thing as an unhandled exception in a task, instead if no
handler is found, the semantics is that the exception is
silently handled, and the task terminates.


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: Exception Propagation

[David C. Hoos, Sr.]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2525 bytes --]


Decker, Christian R wrote in message <0nc73.5376$y6.3195132@WReNphoon3>...
>OK, everyone is mis-understanding my question, and i apologize.....
>I understand that when an exception is raised in a task that it is not
>deterministic as to where the exception gets
>propagated as far as being able to trap and handle it.
>
It _is_ deterministic.  Hear what the RM (11.4) says (note especially
11.4 (4):

3 When an exception occurrence is raised by the execution of a given
construct, the rest of the execution of that construct is abandoned;
that is, any portions of the execution that have not yet taken place
are not performed. The construct is first completed, and then left,
as explained in 7.6.1. Then:

4 � If the construct is a task_body, the exception does not propagate
    further;
5 � If the construct is the sequence_of_statements of a
handled_sequence_of_statements that has a handler with a choice
covering the exception, the occurrence is handled by that handler;
6 � Otherwise, the occurrence is propagated to the innermost
dynamically enclosing execution, which means that the occurrence
is raised again in that context.

>But as far as seeing text displayed in the console window indicating that
an
>excpetion was raised should always
>occur, at least in every other Ada compiler i have used.  My problem is
that
>i see no text, or any other indication
>that an exception is being raised.  I know there is an exception because i
>tested using an explicit trap to display
>the error.  I don't want random exception handles, i just want to be
>notified via text in the console that an
>exception has occured.
>


"Ada 95 Quality and Style: Guidelines for Professional Programmers" has
guidelines that explicitly address this issue, viz.:

Provide a handler for exception Program_Error whenever you cannot avoid
a selective accept statement whose alternatives can all be closed
(Honeywell 1986).

Make systematic use of handlers for Tasking_Error.

Be prepared to handle exceptions during a rendezvous .

Consider using a when others exception handler.

Consider using an exception handler for a rendezvous within the main
loop inside each task.

Place an exception handler for others at the end of a task body.

Consider having each exception handler at the end of a task body report
the task's demise.

>So with that does anyone know why i am not getting text messages telling me
>an exception was raised?
>
Yes .. because If the construct is a task_body, the exception does not
propagate further.

Re: Exception Propagation

[dennison]

In article <0nc73.5376$y6.3195132@WReNphoon3>,
  cdecker@snet.net (Decker, Christian R) wrote:
> OK, everyone is mis-understanding my question, and i apologize.....
> I understand that when an exception is raised in a task that it is not
> deterministic as to where the exception gets
> propagated as far as being able to trap and handle it.

There certianly is a misunderstanding here. I hope I didn't cause it.

What I was trying to say is that an exception is *not* propagated into
any task other than the one it occurred in (except in a rendezvous). If
I were to create language TERD, which did have that behavior, then in
TERD it would be completly non-deterministic in the parent task where an
exception raised from the child task popped up. Therefore there would be
no good way to handle and recover from exceptions in child tasks. That's
probably one reason why the designers of Ada did not do that! In Ada
tasks can only get exceptions from themselves or from tasks they
rendezvous with during the rendezvous. That makes it quite
deterministic.

As for warning you that a task died, in my experinece most compilers do
*not* do that. Whether that is from concerns about synchronizing writes
to standard output, or from sheer lazieness I can't say. But I know that
both Gnat and GreenHills behave that way, and I suspect ObjectAda does
as well.

If you *do* write such code in last-ditch handlers on your tasks, make
sure to handle the IO synchronization problem yourself, or you are
liable to get interspersed output, or different exceptions than the ones
you are looking for.

--
T.E.D.


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: Exception Propagation

[Robert A Duff]

dennison@telepath.com writes:

> What I was trying to say is that an exception is *not* propagated into
> any task other than the one it occurred in (except in a rendezvous). If
> I were to create language TERD, which did have that behavior, then in
> TERD it would be completly non-deterministic in the parent task where an
> exception raised from the child task popped up.

Not necessarily.  Tasks synchronize with their parent whenever a master
is left.  It would make sense to say that at that point, if any
dependent tasks died due to unhandled exception, the parent task then
raises Tasking_Error (or Program_Error)?  Of course, this catches the
error rather late, but at least it's not totally ignored.

Another idea would be to abort the siblings, and then raise
Tasking_Error.

But Robert Dewar's idea is best, I think: An unhandled exception in
*any* task kills the whole program (hopefully with an error message).

It should be a strict language design principle: "Unhandled exceptions
never get lost."  Or, "The default behavior for run-time errors should
be to stop the program".  How many times have I run a shell script that
printed out an error message, and then continued to bumble along in a
confused manner, destroying the evidence and/or valuable data?  At least
Ada doesn't do that in *most* cases.

But Ada does has several other similar cases.  For example, an unhandled
exception in an interrupt handler is lost.  Instead, it should kill the
whole program.  As Robert pointed out, this puts the burden on the
programmer (where it belongs); if the programmer doesn't want the whole
program to die, then an exception handler is called for.

Another example: an unhandled exception in a Finalize procedure.  This
case isn't asynchronous, but it has similar problems: many Finalize
procedures are happening "together", and if two of them die, we don't
know what to do, so we raise Program_Error.  The rules for exactly what
happens when are way too complicated (I wrote them), and they're
extremely difficult to implement efficiently.  I think it would have
been better if the default behavior for Finalize would be to kill the
program; if the programmer wants some other behavior, write a handler.

Another example: Storage_Error.  It can happen pretty much anywhere, so
it's really asynchronous, in a sense.  You can pin it down if you look
at the machine code, but just looking at the semantics of a given Ada
program, it's impossible to predict where it might raise Storage_Error,
so there's not much a program can do about it.

>... Therefore there would be
> no good way to handle and recover from exceptions in child tasks. That's
> probably one reason why the designers of Ada did not do that! In Ada
> tasks can only get exceptions from themselves or from tasks they
> rendezvous with during the rendezvous. 

Not quite true -- if a child dies before its "begin", then the exception
is propagated to the parent.  (Well, it's not really "propagated",
because it turns into Tasking_Error, because it could happen more than
once simultaneously.)

All these cases where exceptions get turned into Tasking_Error or
Program_Error are fairly useless to handle in most cases -- all the
handler knows is "something went wrong".

>...That makes it quite
> deterministic.

That's the key...

> As for warning you that a task died, in my experinece most compilers do
> *not* do that. Whether that is from concerns about synchronizing writes
> to standard output, or from sheer lazieness I can't say. But I know that
> both Gnat and GreenHills behave that way, and I suspect ObjectAda does
> as well.

I'm not sure why, either.  I guess people just say, well, the RM says
it's not an error, so no error message is warranted.  Or maybe people
are afraid of failing the ACVC if they give an error message in a
non-error situation (I'm not sure they would...), which means you need
two different modes, which adds complexity, which maybe isn't worth it.

> If you *do* write such code in last-ditch handlers on your tasks, make
> sure to handle the IO synchronization problem yourself, or you are
> liable to get interspersed output, or different exceptions than the ones
> you are looking for.

Hmm.  Maybe.  But the more complicated you make that exception-handling
code, the more likely that *it* will have the same problem -- and whose
going to handle exceptions in the exception handler?

- Bob
-- 
Change robert to bob to get my real email address.  Sorry.

Re: Exception Propagation

[Bryce Bardin]

Robert A Duff wrote:
> 
> dennison@telepath.com writes:
> 
[snip]
> > If you *do* write such code in last-ditch handlers on your tasks, make
> > sure to handle the IO synchronization problem yourself, or you are
> > liable to get interspersed output, or different exceptions than the ones
> > you are looking for.
> 
> Hmm.  Maybe.  But the more complicated you make that exception-handling
> code, the more likely that *it* will have the same problem -- and whose
> going to handle exceptions in the exception handler?

This is a classic case of:

  "Quis custodiet ipsos custodes?"

  [Who will keep the keepers?]

> 
> - Bob
> --
> Change robert to bob to get my real email address.  Sorry.

Re: Exception Propagation

[dennison]

In article <wccd7yyrgfu.fsf@world.std.com>,
  Robert A Duff <bobduff@world.std.com> wrote:
> dennison@telepath.com writes:
>

> > If you *do* write such code in last-ditch handlers on your tasks,
make
> > sure to handle the IO synchronization problem yourself, or you are
> > liable to get interspersed output, or different exceptions than the
ones
> > you are looking for.
>
> Hmm.  Maybe.  But the more complicated you make that
exception-handling
> code, the more likely that *it* will have the same problem -- and
whose
> going to handle exceptions in the exception handler?

In my experience if you try to use an unprotected Text_IO in last-ditch
exception handlers in a multitask program, you are almost *guaranteed*
to get an exception in your exception handlers. When one task dies, any
task attempting to rendezvous with it will die too. Tasks looking to
rendezvous with those newly dead tasks will then die. Thus task
terminations tend to spread through the system like a cold through a
daycare center. The odds of more than one task trying to simultaniously
do text I/O from its exception handler gets to be awfully close to 1.0

--
T.E.D.


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: Exception Propagation

[Robert A Duff]

dennison@telepath.com writes:

> In my experience if you try to use an unprotected Text_IO in last-ditch
> exception handlers in a multitask program, you are almost *guaranteed*
> to get an exception in your exception handlers. When one task dies, any
> task attempting to rendezvous with it will die too. Tasks looking to
> rendezvous with those newly dead tasks will then die. Thus task
> terminations tend to spread through the system like a cold through a
> daycare center. The odds of more than one task trying to simultaniously
> do text I/O from its exception handler gets to be awfully close to 1.0

Yes, I suppose you're right.

But if the run-time system were in charge of giving that message,
it might be able to do something very low-level and simple.

That's one of the things that bothers me about the way Ada (and/or
implementations) deals with unhandled exceptions.  When something bad
happens, there's a whole lot of mechanism invoked unwinding stacks and
doing finalization -- I want to see an error message *before* all that
stuff obscures what originally went wrong.

- Bob
-- 
Change robert to bob to get my real email address.  Sorry.

Re: Exception Propagation

[Dale Stanbrough]

Robert A Duff wrote:

" The rules for exactly what
  happens when are way too complicated (I wrote them), and they're
  extremely difficult to implement efficiently.  I think it would have
  been better if the default behavior for Finalize would be to kill the
  program; if the programmer wants some other behavior, write a handler."


I've noticed a number of times that you have had second thoughts on some
of the design decisions you made (or maybe Robert Dewar did :-). I was
wondering if you have in mind a better process for establishing standards,
so that the problems described above wouldn't result?


Dale

Re: Exception Propagation

[Robert A Duff]

dale@cs.rmit.edu.au (Dale Stanbrough) writes:

> I've noticed a number of times that you have had second thoughts on some
> of the design decisions you made ...

Not so many, I think.  I have lots of ideas about how to improve Ada in
non-upward-compatible ways.  But that wasn't my job during the Ada 9X
process.  Upward compatibility was a high priority, and rightly so, and
given that constraint, I can only think of a few design decisions that I
now think were clearly wrong.

Besides, I can blame it all on Tucker.  He always had the final say --
although it's surprising that he and I almost always agreed (sometimes
after week-long arguments).  ;-)

>... (or maybe Robert Dewar did :-).

Certainly Robert and I don't always agree -- but I think we *usually*
do.  ;-)

>...I was
> wondering if you have in mind a better process for establishing standards,
> so that the problems described above wouldn't result?

Well, I suppose you could avoid standardizing anything until it's
perfect, and you know it's perfect.  ;-)

No, I don't know how to design a perfect programming language, any more
than I know how to write a large, complicated computer program without
any bugs.

The art of programming language design is still in its infancy.

Sometimes I think Ada 83 would have turned out better if it had been
implemented and used seriously for a couple of years before
standardization.  That would have improved the language in some ways,
but that approach also has drawbacks.  Look at the delay in C++
standardization, and look at the portability problems as C++ compilers
struggle to move their dialects toward the one true standard.

Some folks would say that formal definitions are the key.  They might
help, but I suspect they're no panacea.

Note also that a good-enough standard is better than no standard, and
might be better than a better-but-later standard.  It all depends.

- Bob
-- 
Change robert to bob to get my real email address.  Sorry.

Re: Exception Propagation

[Robert Dewar]

In article <375CC549.7EDFB885@spam.com>,
  spamwithchipsplease@spam.com wrote:
> This feature has escaped me, or I have forgot  ( RM95 11.4(4)
> ), I've
> also checked RM83 and found it to be a feature of that
> language edition.
> I would rather the exception was propogated aleast this gives
> the option
> of deciding whether  the program  terminates or not.

Propagated to where? There really is no possibility of
propagation (you certainly do not want to introduce asynchronous
exceptions for this purpose!)

I would have preferred that an unhandled exception in a task
caused termination of the entire program, you can always get
the bizarre effect in the RM if you really want it by doing:

      exception when others => null;

at the outer level of a task


> Given the RM specification, I think a mandatory "when others"
> task level exception handler would be prudent.

Check your compiler, it may have an option for handling this
error situation nicely. But in general, yes, that's a good idea
(mandatory when others at the top level of a task).


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: Exception Propagation

[Matthew Heaney]

Robert Dewar <robert_dewar@my-deja.com> writes:

> I would have preferred that an unhandled exception in a task
> caused termination of the entire program, you can always get
> the bizarre effect in the RM if you really want it by doing:
> 
>       exception when others => null;
> 
> at the outer level of a task


I don't understand this comment.  

Given this task body:

  task body T is
    ...
  begin
    ...
  exception
    when others => null;

  end T;


Are you saying that if an exception occurs, that that exception handler
will cause behavior other than silent termination of task T?

Re: Exception Propagation

[R. Tim Coslet]

No, he means something like...

  task body T is
    ...
  begin
    ...            -- Do one time task "setup" code here.
    loop
        ...        -- Do task "setup" code needed to "restart" here.
        begin
            ...    -- Main body of task.
        exception
        when others =>
            ...    -- Do "exception recovery & reporting" code here.
        end;
    end loop;

  end T;

This task can not be terminated by any exception, it just "restarts" at the
loop.

The "exception recovery & reporting" code might be null.


            R. Tim Coslet



Matthew Heaney wrote:

> Robert Dewar <robert_dewar@my-deja.com> writes:
>
> > I would have preferred that an unhandled exception in a task
> > caused termination of the entire program, you can always get
> > the bizarre effect in the RM if you really want it by doing:
> >
> >       exception when others => null;
> >
> > at the outer level of a task
>
> I don't understand this comment.
>
> Given this task body:
>
>   task body T is
>     ...
>   begin
>     ...
>   exception
>     when others => null;
>
>   end T;
>
> Are you saying that if an exception occurs, that that exception handler
> will cause behavior other than silent termination of task T?

Re: Exception Propagation

[Robert Dewar]

In article <m3wvxef8zw.fsf@mheaney.ni.net>,
  Matthew Heaney <matthew_heaney@acm.org> wrote:
> Robert Dewar <robert_dewar@my-deja.com> writes:
>
> > I would have preferred that an unhandled exception in a task
> > caused termination of the entire program, you can always get
> > the bizarre effect in the RM if you really want it by doing:
> >
> >       exception when others => null;
> >
> > at the outer level of a task
>
> I don't understand this comment.
>
> Given this task body:
>
>   task body T is
>     ...
>   begin
>     ...
>   exception
>     when others => null;
>
>   end T;
>
> Are you saying that if an exception occurs, that that
> exception handler
> will cause behavior other than silent termination of task T?


No -- I am saying that I would have preferred semantics where
if an exception is unhandled in a task, the entire program is
terminated (as for an unhandled exception in the environment
task). Then if you want the current RM semantics of tasks
going away silently, you program it explicitly as shown above,
though once you are forced to program this explicitly, you
may well get the feeling that "null" is NOT the best choice
of code to write here :-)


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: Exception Propagation

[dennison]

In article <m3wvxef8zw.fsf@mheaney.ni.net>,
  Matthew Heaney <matthew_heaney@acm.org> wrote:
> Robert Dewar <robert_dewar@my-deja.com> writes:
>
> > I would have preferred that an unhandled exception in a task
> > caused termination of the entire program, you can always get
> > the bizarre effect in the RM if you really want it by doing:
> >
> >       exception when others => null;
> >
> > at the outer level of a task
>
> I don't understand this comment.
>
> Given this task body:
>
>   task body T is
>     ...
>   begin
>     ...
>   exception
>     when others => null;
>
>   end T;
>
> Are you saying that if an exception occurs, that that exception
handler
> will cause behavior other than silent termination of task T?

I think you missed the subjunctive clause. He's talking about a
hypothecital scheme where termination of an Ada task via an
unhandled exception causes the entire program to terminate, not actual
Ada. In such a scheme, the *current* behavior of Ada programs (silent
termination) could be achieved by the code above.

The only way I can think of to implement Matt's suggestion would be to
indeed raise the exception in the parent task (in a non-determinstic
location) when a child task is terminated by it, as in my hypothetical
TERD language. :-)

--
T.E.D.


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: Exception Propagation

[dennison]

In article <375CC549.7EDFB885@spam.com>,
  spamwithchipsplease@spam.com wrote:
> dennison@telepath.com wrote:
> > That's the behavior I'd expect to see if the exception is occuring
in a
> > task. The whole program doesn't terminate just because one task
dies.
>
> This feature has escaped me, or I have forgot  ( RM95 11.4(4) ), I've
> also checked RM83 and found it to be a feature of that language
edition.
> I would rather the exception was propogated aleast this gives the
option
> of deciding whether  the program  terminates or not.

It wouldn't make much sense for that to happen. That would mean a task
(or the main routine) which had a child task could conveivably raise any
exception at any point in its execution. How would you write code to
handle and recover from that?

If you *do* want one task to raise an exception in another, just raise
the exception in a rendezvous. In that case, *both* tasks get the
exception.

>
> Given the RM specification, I think a mandatory "when others" task
level
> exception handler would be prudent.

That's what we do here, although there are probably situations where
that would be inadvisable. For example, OpenToken puts some extra
diagnotic information in Exception_Message whenever it (manually) raises
an exception. You wouldn't loose that with your exception handler, but
you would have to be smart enough to dump the exception information
somewhere before you leave the handler. Also, there's nothing stopping
some nice compiler vendor from dumping a stack trace for
exception-terminated tasks to stdout. But none of the ones I use are
that nice.

Following is one of my task outer exception handlers. Note that
"Log.Report" is a utility of ours that handles I/O in a task-safe manner
(Text_IO does not). Often task terminations cause cascading errors in
other tasks, which can cause contention for the I/O device. Its annoying
to get I/O exceptions when you should be getting details about the
*real* exception that caused the problem.:

   exception
      when Error : others =>
         Log.Report (Event => "Save_Restore.Data_Dispatcher terminated
due to " &
                     "unhandled exception." & Ada.Characters.Latin_1.Cr
&
                     Ada.Characters.Latin_1.Lf &
                     Ada.Exceptions.Exception_Information (Error),
                     Severity => Log.Error);

--
T.E.D.


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Exception propagation

[REH]

I found this "In a distributed program, the identity is unique across
an entire program, not just across a single partition. Exception
propagation works properly across RPC's. An exception can be propagated
from one partition to another, and then back to the first, where its
identity is known. " in the ARM.

Does this mean that the id of an exception is identical in each
partition? So, if I am using a partitioned OS, can I send an
exception's id from one partition to another and reliably raise it?

REH

Re: Exception propagation

[Ludovic Brenta]

"REH" <spamjunk@stny.rr.com> writes:
> I found this "In a distributed program, the identity is unique across
> an entire program, not just across a single partition. Exception
> propagation works properly across RPC's. An exception can be propagated
> from one partition to another, and then back to the first, where its
> identity is known. " in the ARM.
>
> Does this mean that the id of an exception is identical in each
> partition? So, if I am using a partitioned OS, can I send an
> exception's id from one partition to another and reliably raise it?

I am under the impression that you confuse the Ada notion of a
"partition" and the OS notion; please correct me if I'm wrong.

In Ada, you have one "program" distributed in "partitions".
Partitions may run on the same or on different computers; for example
a FreeDOS machine may run only one partition at a time, but GNU/Linux
can run several, as each partition is a process.  You may also use a
bare board embedded computer to run a single partition with no
operating system underneath it.

In operating systems, "partitions" all run on the same physical
system, and each "partition" contains an instance of an operating
system.  At least, that's the terminology used by e.g. IBM with "LPAR"
- logical partitions.  This technology appeared first on mainframes,
then migrated to AS/400 (now iSeries), then RS/6000 (now pSeries) and
is finally reaching low-end x86 boxes now.

The Ada distributed systems annex says that the run-time system will
propagate an exception from one "Ada" partition to another, wherever
they may be.  And yes, the ID of the exception is the same in all Ada
partitions, since together they form one single Ada program.  And yes,
if you happen to run several instances of an operating system on one
server ("LPAR"), each containing one or more of your Ada partitions,
then exceptions will propagate from one LPAR to another, and even from
one physical computer to another if that's what you need.

You don't send the ID of an exception, because you comile all your
partitions together as one program; thus each partition has the same
table of exception definitions.  You just "raise" in a subprogram in
one partition and handle in the possibly different partition
containing the calling subprogram.

Does that answer your question?

-- 
Ludovic Brenta.

Re: Exception propagation

[REH]

Ludovic Brenta wrote:
> "REH" <spamjunk@stny.rr.com> writes:
> > I found this "In a distributed program, the identity is unique across
> > an entire program, not just across a single partition. Exception
> > propagation works properly across RPC's. An exception can be propagated
> > from one partition to another, and then back to the first, where its
> > identity is known. " in the ARM.
> >
> > Does this mean that the id of an exception is identical in each
> > partition? So, if I am using a partitioned OS, can I send an
> > exception's id from one partition to another and reliably raise it?
>
> I am under the impression that you confuse the Ada notion of a
> "partition" and the OS notion; please correct me if I'm wrong.
>
Well, I'm not sure.  What if I have a partitioned Ada program running
in a partitioned OS?  What I wasn't sure of was whether I could take an
exception raised in one address space, and send it to another address
space and re-raise it.  We are using Integrity.  I was told I must use
connections (and not the RPC services in the distributed annex) because
they are faster.  Whether that is true or not, I do not know.  What I
am wondering (I have no hardware or software yet, so I cannot do any
prototyping), is will the two "pieces" of Ada, which are in separate
address spaces but built as one monolithic object, have the same
exception id mapping.  Since I have to use connection objects, I have
to handle the exception propagation myself.  I am trying to figure out
if I need to convert the exception ids to a common value both pieces of
Ada can agree on, like an enumeration, or if that is unnecessary
because the pieces already agree on the values of the ids.

Is it even possible to have a partitioned Ada program without using the
distributed services annex?

Does that make sense?

REH

Re: Exception propagation

[Ludovic Brenta]

"REH" <spamjunk@stny.rr.com> writes:

> Ludovic Brenta wrote:
>> "REH" <spamjunk@stny.rr.com> writes:
>> > I found this "In a distributed program, the identity is unique across
>> > an entire program, not just across a single partition. Exception
>> > propagation works properly across RPC's. An exception can be propagated
>> > from one partition to another, and then back to the first, where its
>> > identity is known. " in the ARM.
>> >
>> > Does this mean that the id of an exception is identical in each
>> > partition? So, if I am using a partitioned OS, can I send an
>> > exception's id from one partition to another and reliably raise it?
>>
>> I am under the impression that you confuse the Ada notion of a
>> "partition" and the OS notion; please correct me if I'm wrong.
>>
> Well, I'm not sure.  What if I have a partitioned Ada program running
> in a partitioned OS?  What I wasn't sure of was whether I could take an
> exception raised in one address space, and send it to another address
> space and re-raise it.  We are using Integrity.  I was told I must use
> connections (and not the RPC services in the distributed annex) because
> they are faster.  Whether that is true or not, I do not know.  What I
> am wondering (I have no hardware or software yet, so I cannot do any
> prototyping), is will the two "pieces" of Ada, which are in separate
> address spaces but built as one monolithic object, have the same
> exception id mapping.  Since I have to use connection objects, I have
> to handle the exception propagation myself.  I am trying to figure out
> if I need to convert the exception ids to a common value both pieces of
> Ada can agree on, like an enumeration, or if that is unnecessary
> because the pieces already agree on the values of the ids.
>
> Is it even possible to have a partitioned Ada program without using
> the distributed services annex?

No, not in the sense of the Ada distributed systems annex.  Whoever
said you must use "connections" instead of "RPC" was thinking in terms
of low-level OS services, and does not display understanding of the
distributed systems annex.  The DSA sits on top of the OS, and uses
whatever services are available.  The DSA then guarantees that all
partitions agree on the same exception definitions, and provides a
common protocol for exception propagation.

If you can't or won't use the DSA, then you're pretty much on your
own, and you have to solve the problems of common definition,
propagation and handling.  Instead of one partitioned program in the
sense of the DSA, you will have several Ada programs talking to each
other, much like you would do in lesser languages.

Unfortunately, it seems you're in that situation, as Green Hills
doesn't support the DSA, or even provide an implementation of it.
Only AdaCore provides an implementation, called GLADE.  With GLADE,
you first compile and test your program as one monolithic executable;
then you use "gnatdist" to split that program into one executable file
per partition.  GLADE does the rest.  It's really very easy to do.

> Does that make sense?

Now it does.

HTH

-- 
Ludovic Brenta.

Re: Exception propagation

[REH]

"Ludovic Brenta" <ludovic@ludovic-brenta.org> wrote in message 
news:87k6auatqc.fsf@ludovic-brenta.org...
>> Is it even possible to have a partitioned Ada program without using
>> the distributed services annex?
>
> No, not in the sense of the Ada distributed systems annex.  Whoever
> said you must use "connections" instead of "RPC" was thinking in terms
> of low-level OS services, and does not display understanding of the
> distributed systems annex.  The DSA sits on top of the OS, and uses
> whatever services are available.  The DSA then guarantees that all
> partitions agree on the same exception definitions, and provides a
> common protocol for exception propagation.
>
> If you can't or won't use the DSA, then you're pretty much on your
> own, and you have to solve the problems of common definition,
> propagation and handling.  Instead of one partitioned program in the
> sense of the DSA, you will have several Ada programs talking to each
> other, much like you would do in lesser languages.
>
> Unfortunately, it seems you're in that situation, as Green Hills
> doesn't support the DSA, or even provide an implementation of it.
> Only AdaCore provides an implementation, called GLADE.  With GLADE,
> you first compile and test your program as one monolithic executable;
> then you use "gnatdist" to split that program into one executable file
> per partition.  GLADE does the rest.  It's really very easy to do.
>
Very informative.  Thank you!

REH

Re: Exception propagation

[Georg Bauhaus]

REH wrote:
> "Ludovic Brenta" <ludovic@ludovic-brenta.org> wrote in message 
> news:87k6auatqc.fsf@ludovic-brenta.org...
>>> Is it even possible to have a partitioned Ada program without using
>>> the distributed services annex?
>> No, not in the sense of the Ada distributed systems annex.
> Very informative.  Thank you!

FWIW, Thomas Quinot has given an overview of possible DS
implementation strategies at FOSDEM 2006. It doesn't address
exception handling specifically, though. (I'm sure Ludovic knows
this so maybe if there is a reason for not linking to the site
below, please excuse.)

The slides used are linked from here,
http://www.cs.kuleuven.be/~dirk/ada-belgium/events/06/060226-fosdem.html



-- Georg