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: a07f3367d7,6327f05d4989a68d X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII-7-bit X-Received: by 10.180.19.194 with SMTP id h2mr9946055wie.0.1356837413530; Sat, 29 Dec 2012 19:16:53 -0800 (PST) MIME-Version: 1.0 Path: i11ni337243wiw.0!nntp.google.com!feeder1.cambriumusenet.nl!82.197.223.103.MISMATCH!feeder3.cambriumusenet.nl!82.197.223.108.MISMATCH!feeder2.cambriumusenet.nl!feed.tweaknews.nl!85.12.40.139.MISMATCH!xlned.com!feeder7.xlned.com!newsfeed10.multikabel.net!multikabel.net!newsfeed20.multikabel.net!border3.nntp.ams.giganews.com!border1.nntp.ams.giganews.com!border4.nntp.ams.giganews.com!border2.nntp.ams.giganews.com!nntp.giganews.com!newsreader4.netcologne.de!news.netcologne.de!news.mixmin.net!newsfeed.x-privat.org!news.jacob-sparre.dk!munin.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Press Release - Ada 2012 Language Standard Approved by ISO Date: Thu, 27 Dec 2012 15:54:59 -0600 Organization: Jacob Sparre Andersen Research & Innovation Message-ID: References: <7wrdmbre6jw9.qww9l0uzj6mg.dlg@40tude.net> <14oqoq06zhlu2.tcasif3hdyhw.dlg@40tude.net> <1drh1q1ln2dfh$.a9hwlg01fjfy.dlg@40tude.net> <50d6365d$0$6577$9b4e6d93@newsspool3.arcor-online.net> <1pbg79bz92j3t$.sz41zduivjfp.dlg@40tude.net> <4c101d74-c8cb-45a6-82d4-91923bb950b0@googlegroups.com> <87sj6tre9s.fsf@mid.deneb.enyo.de> <895c9eb7-03f8-4b0c-96b4-3dbd7a315ccd@googlegroups.com> NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: munin.nbi.dk 1356645304 27371 69.95.181.76 (27 Dec 2012 21:55:04 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Thu, 27 Dec 2012 21:55:04 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Response X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Date: 2012-12-27T15:54:59-06:00 List-Id: "Jeffrey Carter" wrote in message news:kbi56i$plr$1@dont-email.me... > On 12/27/2012 08:30 AM, Dmitry A. Kazakov wrote: >> >> >> And a nice race condition coming with that! Never use File_Exists if you >> can. > > Precisely. Multiple processes may access the file system at the same time. > The idea that you can check the precondition to an operation and have the > result still hold when you invoke the operation is only valid for > sequential activities; when you're using a concurrent language like Ada > then there are often cases when that's a race. The Get operation for a > concurrent, non-blocking queue has the precondition "not Is_Empty", but > between checking that and invoking Get another task may have changed the > state of the queue. And not just tasks in your program, but processes from other programs running on the machine, programs from other machines accessing your file system, and of course, the wetware (you) running the computer can change the state of the file system. Moreover, it's not just file system operations that behave this way. Almost any interactions with the underlying system have this property (memory management, networking, GUI, etc.). This was a major consideration for the design of Claw -- everything raises exceptions because the operation of the GUI is necessarily asynchonous WRT to your program: the wetware running the program can click on the 'x' and close a window while the program is referencing it. There is no sane way to stop that (you can block those operations for a while, but doing it for long makes the GUI unresponsive). You can only handle errors, you cannot prevent them beforehand. Dmitry also touched on the fact that prechecking can be too expensive to use in common scenarios. For instance, End_of_File is about as costly as Get when using Text_IO. If your program reads single characters, you're doubling the I/O time if you pretest with End_of_File (and if you are reading large files in a tight loop, that can make a significant performance difference - especially as Text_IO is slow anyway). Randy.