From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,d676a4bf883e6826 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII Path: g2news1.google.com!news1.google.com!proxad.net!news.wiretrip.org!border2.nntp.ams.giganews.com!nntp.giganews.com!feeder.news-service.com!post.news-service.com!news1.surfino.com!not-for-mail Message-Id: <2769994.nWUuW2bqkI@linux1.krischik.com> From: Martin Krischik Subject: Re: task synchronization and activation Newsgroups: comp.lang.ada Reply-To: martin@krischik.com Date: Wed, 23 Feb 2005 08:58:14 +0100 References: <5f59677c.0502190711.1d6d2492@posting.google.com> <3bmevc.5mi.ln@hunter.axlog.fr> Organization: None User-Agent: KNode/0.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 8Bit X-Complaints-To: abuse@surfino.com NNTP-Posting-Host: 83.169.175.19 (83.169.175.19) NNTP-Posting-Date: Wed, 23 Feb 2005 09:00:08 +0100 X-Trace: 06dd6421c3808f60c0ab620648 Xref: g2news1.google.com comp.lang.ada:8465 Date: 2005-02-23T08:58:14+01:00 List-Id: Robert A Duff wrote: > Jean-Pierre Rosen writes: > >> Robert A Duff a �crit : >> [...] >> > I can believe that that was the reasoning of the Ada 83 designers. >> > But I still don't quite agree with it. >> > For one thing, if you want to handle exceptions in the decl part, >> > just change this: >> > task body T is >> > ... -- possible exception here? >> > begin >> > ... >> > end T; >> > to this: >> > task body T is >> > begin >> > declare >> > ... -- possible exception here? >> > begin >> > ... >> > end; >> > exception >> > ... >> > end T; >> > and now the task can handle it (because it's no longer in the task's >> > declarative part). So it's a case of "Doctor, it hurts when I...." >> > "So don't do that." ;-) >> >> It is not the same thing *at all*. Here, you are putting the >> responsibility on the task's side, but the issue is to be safe from the >> caller's point of view. >> >> Let's look at it differently. A program unit needs some subtasks to do >> its job. If the subtasks cannot be started for any reason (including >> storage_error), then the program unit cannot work, and it'd better be >> noticed of that; most likely, the program unit will raise an exception >> or find a fall-back strategy. Since asynchronous exceptions are horrible >> (Java did that mistake, and had to back-up), this must happen >> synchronously, and the logical point is just before executing any >> statement. >> >> Now, you can argue that the subtasks may fail at any later time; > > Yes, I do argue exactly that. ;-) > >>... that's >> true, and Tasking_Error may be raised for any interaction. However, >> failing activation is basically not having the resources to start the >> servers, and is a much more severe condition. > > Failing activation (i.e. raising an exception before "begin") could be > due to lack of resources, or a bug, or any other cause of exceptions. > Exceptions *after* "begin" can also be caused by any of these -- > including running out of resources. So I don't see any reason to > believe that exceptions before the begin are more severe, or deserve an > automatic means of notification -- let the programmer decide which > exceptions are severe, and how/who should be notified. Exceptions after the begin can be handled by the task itself while exceptions before can not. Look at the following simple no task example: Outer : declare Inner : declare type T is access .... A : T := new ... B : T; begin B := new .... exception when Storage_Error => -- hande new B end Inner; exception when Storage_Error => -- handle new A end Outer; > Actually, I'd say exceptions in an exception handler are typically more > severe than others, because they represent failure of a failure-recovery > mechanism. But I still think the programmer, not the language designer, > should make such decisions. There is an important difference in exceptions handling for statemens before and after begin. And with the current solution both task and no task environments are consistant with each other. Change one and you have to change the other as well. And yes, I have quite a few procedures with start with: Try : declare for precicly that reason. If you don't want the activator task to wait you have to to the same as when you want a write "no raise" procedure: task body T is begin Try: declare .... exception .... end Try; end T; Sidenote: I usualy need "no raise" procedures for interfacing with C. > Anyway, passing the "begin" is no indication that the task is ready to > go. Putting code before and after "begin" is determined by all kinds of > unrelated issues (like if you want to call a subprogram that creates a > String, you normally have to use a function result, rather than an 'out' > parameter, so it comes before "begin", whereas if you want to initialize > a variable with a loop, that comes after "begin"). A task is ready to > receive entry calls when it reaches an accept -- "begin" is irrelevant. But it is all about exception handling. And it is consitant with procedures and functions as it is. Martin -- mailto://krischik@users.sourceforge.net Ada programming at: http://ada.krischik.com