Re: Press Release - Ada 2012 Language Standard Approved by ISO

["Randy Brukardt" <randy@rrsoftware.com>]

"Jeffrey Carter" <spam.jrcarter.not@spam.not.acm.org> 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.