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=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,4fe0da28a190b761 X-Google-Attributes: gid103376,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news1.google.com!news2.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!newsfeed00.sul.t-online.de!t-online.de!news.albasani.net!feeder.erje.net!feeder2.news.saunalahti.fi!fi.sn.net!newsfeed2.fi.sn.net!news.song.fi!not-for-mail Date: Fri, 07 Nov 2008 14:12:30 +0200 From: Niklas Holsti User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20060628 Debian/1.7.8-1sarge7.1 X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Storage management References: <87fxmbog1u.fsf@mid.deneb.enyo.de> <87abciurrl.fsf@mid.deneb.enyo.de> <13hpf6ht4tl2m$.1su6rgr67eb2o$.dlg@40tude.net> <49140215$0$23600$4f793bc4@news.tdc.fi> <1pqpgcv6v4qxq$.1wkkgkw2yncf.dlg@40tude.net> In-Reply-To: <1pqpgcv6v4qxq$.1wkkgkw2yncf.dlg@40tude.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <49142285$0$23584$4f793bc4@news.tdc.fi> Organization: TDC Internet Services NNTP-Posting-Host: laku61.adsl.netsonic.fi X-Trace: 1226056325 news.tdc.fi 23584 81.17.205.61:32829 X-Complaints-To: abuse@tdcnet.fi Xref: g2news1.google.com comp.lang.ada:2612 Date: 2008-11-07T14:12:30+02:00 List-Id: Dmitry A. Kazakov wrote: > On Fri, 07 Nov 2008 11:54:05 +0200, Niklas Holsti wrote: > > >>Dmitry A. Kazakov wrote: >> >>>I have a general question. Does anybody use abort >>>and asynchronous transfer of control? >> >>I do, to set a limit on the running time of a possibly lengthy >>procedure Analyse: >> >> select >> delay Opt.Max_Analysis_Time; >> Output.Error ("Maximum analysis time exceeded."); >> then abort >> Analyse; >> end select; > > > That does not look like a good example. In such cases there > would be some GUI with progress indication stuff, etc. I mean > that most likely Analyse would periodically call something in > order to indicate its state; store the results etc. These > would be natural candidates to abort it "cooperatively," > through an exception propagation. This example is a batch program -- no GUI, no interaction. The most unpredictable part of the execution time is spent waiting for a child process to respond, using blocking I/O to read a pipe that carries the standard output channel of the child process. The child process can get stuck (take a very long time) at any point, so it is not enough to make Analyse check the elapsed time after every pipe-read, for example. If this example had a GUI, it would not need a programmed delay-then-abort time-out; the user would get bored and would click something to abort the child process, which would make the Analyse procedure terminate, too. > I honestly believe that the only case that may justify > abort/ATC is cancellation of an outstanding blocking I/O. Which is the case in my example. I think that abort/ATC is also useful in hard real-time systems as a guard against a task overrunning its deadlines (although execution-time budgeting is an alternative, perhaps better). It is difficult and error-prone to embed overrun-checking code in the task itself, and it will complicate the code -- poor "separation of concerns". > But exactly this case is not guaranteed to work, or rather > is guaranteed not to work... Aborting blocking I/O is "guaranteed not to work"? Can you explain why? Is this something that has been discussed before on c.l.a.? >> Isn't pragma Restrictions (No_Select_Statements) enough? >> Or is it too strong, and a new restriction specifically >> for ATC would be better? > > I would prefer pragma Cancelable put on a task. If a task > is not cancelable then abort would raise Tasking_Error, > and an ATC in the task body would be a compile-time error. I will leave it to the language experts to comment on that suggestion. I assume it would have to forbid ATCs in subprograms called from the task, too, which would require some form of subprogram-level contract that the subprogram body executes no ATCs. What about ctrl-C, that is, process abort from the operating system? I don't think that users would be happy if Ada applications could not be aborted with ctrl-C. Do abort-deferred operations now defer ctrl-C, too? -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ .