* Exception Propagation @ 1999-06-07 0:00 Decker, Christian R 1999-06-07 0:00 ` dennison 0 siblings, 1 reply; 25+ messages in thread From: Decker, Christian R @ 1999-06-07 0:00 UTC (permalink / raw) 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 - ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Exception Propagation 1999-06-07 0:00 Exception Propagation Decker, Christian R @ 1999-06-07 0:00 ` dennison 1999-06-08 0:00 ` Glen 0 siblings, 1 reply; 25+ messages in thread From: dennison @ 1999-06-07 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Exception Propagation 1999-06-07 0:00 ` dennison @ 1999-06-08 0:00 ` Glen 1999-06-08 0:00 ` dennison ` (2 more replies) 0 siblings, 3 replies; 25+ messages in thread From: Glen @ 1999-06-08 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Exception Propagation 1999-06-08 0:00 ` Glen @ 1999-06-08 0:00 ` dennison 1999-06-08 0:00 ` Robert Dewar 1999-06-08 0:00 ` Decker, Christian R 2 siblings, 0 replies; 25+ messages in thread From: dennison @ 1999-06-08 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Exception Propagation 1999-06-08 0:00 ` Glen 1999-06-08 0:00 ` dennison @ 1999-06-08 0:00 ` Robert Dewar 1999-06-09 0:00 ` Matthew Heaney 1999-06-08 0:00 ` Decker, Christian R 2 siblings, 1 reply; 25+ messages in thread From: Robert Dewar @ 1999-06-08 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Exception Propagation 1999-06-08 0:00 ` Robert Dewar @ 1999-06-09 0:00 ` Matthew Heaney 1999-06-08 0:00 ` R. Tim Coslet ` (2 more replies) 0 siblings, 3 replies; 25+ messages in thread From: Matthew Heaney @ 1999-06-09 0:00 UTC (permalink / raw) 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? ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Exception Propagation 1999-06-09 0:00 ` Matthew Heaney @ 1999-06-08 0:00 ` R. Tim Coslet 1999-06-09 0:00 ` dennison 1999-06-09 0:00 ` Robert Dewar 2 siblings, 0 replies; 25+ messages in thread From: R. Tim Coslet @ 1999-06-08 0:00 UTC (permalink / raw) 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? ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Exception Propagation 1999-06-09 0:00 ` Matthew Heaney 1999-06-08 0:00 ` R. Tim Coslet @ 1999-06-09 0:00 ` dennison 1999-06-09 0:00 ` Robert Dewar 2 siblings, 0 replies; 25+ messages in thread From: dennison @ 1999-06-09 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Exception Propagation 1999-06-09 0:00 ` Matthew Heaney 1999-06-08 0:00 ` R. Tim Coslet 1999-06-09 0:00 ` dennison @ 1999-06-09 0:00 ` Robert Dewar 2 siblings, 0 replies; 25+ messages in thread From: Robert Dewar @ 1999-06-09 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Exception Propagation 1999-06-08 0:00 ` Glen 1999-06-08 0:00 ` dennison 1999-06-08 0:00 ` Robert Dewar @ 1999-06-08 0:00 ` Decker, Christian R 1999-06-08 0:00 ` Robert Dewar ` (2 more replies) 2 siblings, 3 replies; 25+ messages in thread From: Decker, Christian R @ 1999-06-08 0:00 UTC (permalink / raw) 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 - ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Exception Propagation 1999-06-08 0:00 ` Decker, Christian R @ 1999-06-08 0:00 ` Robert Dewar 1999-06-08 0:00 ` David C. Hoos, Sr. 1999-06-09 0:00 ` dennison 2 siblings, 0 replies; 25+ messages in thread From: Robert Dewar @ 1999-06-08 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Exception Propagation 1999-06-08 0:00 ` Decker, Christian R 1999-06-08 0:00 ` Robert Dewar @ 1999-06-08 0:00 ` David C. Hoos, Sr. 1999-06-09 0:00 ` dennison 2 siblings, 0 replies; 25+ messages in thread From: David C. Hoos, Sr. @ 1999-06-08 0:00 UTC (permalink / raw) [-- 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. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Exception Propagation 1999-06-08 0:00 ` Decker, Christian R 1999-06-08 0:00 ` Robert Dewar 1999-06-08 0:00 ` David C. Hoos, Sr. @ 1999-06-09 0:00 ` dennison 1999-06-14 0:00 ` Robert A Duff 2 siblings, 1 reply; 25+ messages in thread From: dennison @ 1999-06-09 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Exception Propagation 1999-06-09 0:00 ` dennison @ 1999-06-14 0:00 ` Robert A Duff 1999-06-14 0:00 ` dennison ` (2 more replies) 0 siblings, 3 replies; 25+ messages in thread From: Robert A Duff @ 1999-06-14 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Exception Propagation 1999-06-14 0:00 ` Robert A Duff @ 1999-06-14 0:00 ` dennison 1999-06-15 0:00 ` Robert A Duff 1999-06-14 0:00 ` Bryce Bardin 1999-06-15 0:00 ` Dale Stanbrough 2 siblings, 1 reply; 25+ messages in thread From: dennison @ 1999-06-14 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Exception Propagation 1999-06-14 0:00 ` dennison @ 1999-06-15 0:00 ` Robert A Duff 0 siblings, 0 replies; 25+ messages in thread From: Robert A Duff @ 1999-06-15 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Exception Propagation 1999-06-14 0:00 ` Robert A Duff 1999-06-14 0:00 ` dennison @ 1999-06-14 0:00 ` Bryce Bardin 1999-06-15 0:00 ` Dale Stanbrough 2 siblings, 0 replies; 25+ messages in thread From: Bryce Bardin @ 1999-06-14 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Exception Propagation 1999-06-14 0:00 ` Robert A Duff 1999-06-14 0:00 ` dennison 1999-06-14 0:00 ` Bryce Bardin @ 1999-06-15 0:00 ` Dale Stanbrough 1999-06-15 0:00 ` Robert A Duff 2 siblings, 1 reply; 25+ messages in thread From: Dale Stanbrough @ 1999-06-15 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Exception Propagation 1999-06-15 0:00 ` Dale Stanbrough @ 1999-06-15 0:00 ` Robert A Duff 0 siblings, 0 replies; 25+ messages in thread From: Robert A Duff @ 1999-06-15 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Exception propagation @ 2006-03-15 15:16 REH 2006-03-16 21:29 ` Ludovic Brenta 0 siblings, 1 reply; 25+ messages in thread From: REH @ 2006-03-15 15:16 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Exception propagation 2006-03-15 15:16 Exception propagation REH @ 2006-03-16 21:29 ` Ludovic Brenta 2006-03-16 22:19 ` REH 0 siblings, 1 reply; 25+ messages in thread From: Ludovic Brenta @ 2006-03-16 21:29 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Exception propagation 2006-03-16 21:29 ` Ludovic Brenta @ 2006-03-16 22:19 ` REH 2006-03-16 22:51 ` Ludovic Brenta 0 siblings, 1 reply; 25+ messages in thread From: REH @ 2006-03-16 22:19 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Exception propagation 2006-03-16 22:19 ` REH @ 2006-03-16 22:51 ` Ludovic Brenta 2006-03-17 2:52 ` REH 0 siblings, 1 reply; 25+ messages in thread From: Ludovic Brenta @ 2006-03-16 22:51 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Exception propagation 2006-03-16 22:51 ` Ludovic Brenta @ 2006-03-17 2:52 ` REH 2006-03-17 14:52 ` Georg Bauhaus 0 siblings, 1 reply; 25+ messages in thread From: REH @ 2006-03-17 2:52 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Exception propagation 2006-03-17 2:52 ` REH @ 2006-03-17 14:52 ` Georg Bauhaus 0 siblings, 0 replies; 25+ messages in thread From: Georg Bauhaus @ 2006-03-17 14:52 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 25+ messages in thread
end of thread, other threads:[~2006-03-17 14:52 UTC | newest] Thread overview: 25+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1999-06-07 0:00 Exception Propagation Decker, Christian R 1999-06-07 0:00 ` dennison 1999-06-08 0:00 ` Glen 1999-06-08 0:00 ` dennison 1999-06-08 0:00 ` Robert Dewar 1999-06-09 0:00 ` Matthew Heaney 1999-06-08 0:00 ` R. Tim Coslet 1999-06-09 0:00 ` dennison 1999-06-09 0:00 ` Robert Dewar 1999-06-08 0:00 ` Decker, Christian R 1999-06-08 0:00 ` Robert Dewar 1999-06-08 0:00 ` David C. Hoos, Sr. 1999-06-09 0:00 ` dennison 1999-06-14 0:00 ` Robert A Duff 1999-06-14 0:00 ` dennison 1999-06-15 0:00 ` Robert A Duff 1999-06-14 0:00 ` Bryce Bardin 1999-06-15 0:00 ` Dale Stanbrough 1999-06-15 0:00 ` Robert A Duff -- strict thread matches above, loose matches on Subject: below -- 2006-03-15 15:16 Exception propagation REH 2006-03-16 21:29 ` Ludovic Brenta 2006-03-16 22:19 ` REH 2006-03-16 22:51 ` Ludovic Brenta 2006-03-17 2:52 ` REH 2006-03-17 14:52 ` Georg Bauhaus
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox