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,4fe0da28a190b761 X-Google-Attributes: gid103376,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news4.google.com!proxad.net!feeder1-2.proxad.net!news.wiretrip.org!border1.nntp.ams.giganews.com!nntp.giganews.com!newsfeeder.ewetel.de!npeer.de.kpn-eurorings.net!npeer-ng1.kpn.DE!newsfeed.arcor.de!newsspool1.arcor-online.net!news.arcor.de.POSTED!not-for-mail From: "Dmitry A. Kazakov" Subject: Re: Storage management Newsgroups: comp.lang.ada User-Agent: 40tude_Dialog/2.0.15.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Reply-To: mailbox@dmitry-kazakov.de Organization: cbb software GmbH 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> <49142285$0$23584$4f793bc4@news.tdc.fi> Date: Fri, 7 Nov 2008 14:22:36 +0100 Message-ID: NNTP-Posting-Date: 07 Nov 2008 14:22:36 CET NNTP-Posting-Host: 828db945.newsspool4.arcor-online.net X-Trace: DXC=IYIeZTOW6R5;]cDoEWD6A44IUKkg24:KEGV37ON9 X-Complaints-To: usenet-abuse@arcor.de Xref: g2news1.google.com comp.lang.ada:2614 Date: 2008-11-07T14:22:36+01:00 List-Id: On Fri, 07 Nov 2008 14:12:30 +0200, Niklas Holsti wrote: > Dmitry A. Kazakov wrote: >> >> 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.? I don't know. But I discussed that with AdaCore people. Since the following does not work with GNAT Pro 6.2 (Windows wavefront): with Ada.Text_IO; use Ada.Text_IO; procedure Test_ATC is begin Put_Line ("Type"); select delay 2.0; Put_Line ("Timed out"); then abort Put_Line ("You typed " & Get_Line); end select; end Test_ATC; Actually I was almost certain that this were *not* required to work. I only wished to know if they considered it as nice to have working or not. (:-)) There is no way Ada could abort I/O if the OS does not allow this. Second to Get_Line, or likely the first wanted case is canceling blocking socket read. I would give 98% that it never will work with ATC. >>> 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. Or to constrain its use like with the selective accept. > 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? The meaning of ctrl-C depends on the OS. Ada standard cannot mandate that pressing ctrl-C is equivalent to aborting the environment task in the sense of "abort" statement. Then usually OS have efficient means to kill a process preemptively bypassing any "abort deferred" stuff. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de