Files and controlled types

Files and controlled types

[Maciej Sobczak]

Hi,

File types are not Controlled.
What is the rationale for this?

I would think that types associated with external resources should be
Controlled to facilitate resource management in the presence of
exceptions - in this context the file types in the Ada standard
library seem to be designed against this common policy.

--
Maciej Sobczak * www.msobczak.com * www.inspirel.com

Re: Files and controlled types

[gpriv]

On Mar 8, 4:22 pm, Maciej Sobczak <see.my.homep...@gmail.com> wrote:
> Hi,
>
> File types are not Controlled.
> What is the rationale for this?
>
> I would think that types associated with external resources should be
> Controlled to facilitate resource management in the presence of
> exceptions - in this context the file types in the Ada standard
> library seem to be designed against this common policy.
>
> --
> Maciej Sobczak *www.msobczak.com*www.inspirel.com

Don't know about rationale (might be compatibility issue with Ada 83).
I use files mostly directly or as instantiated generics encapsulated
inside other classes (which may be derived from limited controlled) to
do automatic cleanup when needed.  Those are pretty much like C
FILEs.  I have issues with Root_Stream_Type being not controlled
type.  That seems to be bigger drawback.

Regards,

George Privalov

Re: Files and controlled types

[Jeffrey R. Carter]

Maciej Sobczak wrote:
> 
> File types are not Controlled.
> What is the rationale for this?

What makes you think they're not controlled. The ARM only gives the public view, 
which is limited private; there's nothing to prevent the full view from being 
controlled. In addition, the descriptions of Ada.Sequential_IO, Ada.Direct_IO, 
and Ada.Text_IO all include the language "The type File_Type needs finalization 
(see 7.6)".

-- 
Jeff Carter
"No one is to stone anyone until I blow this whistle,
do you understand? Even--and I want to make this
absolutely clear--even if they do say, 'Jehovah.'"
Monty Python's Life of Brian
74

Re: Files and controlled types

[Maciej Sobczak]

On 9 Mar, 04:12, "Jeffrey R. Carter" <spam.jrcarter....@spam.acm.org>
wrote:

> > File types are not Controlled.
> > What is the rationale for this?
>
> What makes you think they're not controlled.

a) AARM
b) trivial test

> The ARM only gives the public view,
> which is limited private; there's nothing to prevent the full view from being
> controlled.

There is nothing that mandates it and therefore I have to assume it is
not done. This is actually what I see in tests.

> In addition, the descriptions of Ada.Sequential_IO, Ada.Direct_IO,
> and Ada.Text_IO all include the language "The type File_Type needs finalization
> (see 7.6)".

This is very good - I haven't notice it.
It is very good, because then instead of broken library definition we
can talk about implementation bugs - these are easier to fix.

My little test follows:

with Ada.Text_IO;
procedure A is

   procedure New_File (I : in Integer) is
      Name : String := "temp/" & Integer'Image (I) & ".txt";
      F : Ada.Text_IO.File_Type;
   begin
      Ada.Text_IO.Put_Line ("Opening " & Name);
      Ada.Text_IO.Create (F, Ada.Text_IO.Out_File, Name);
--      Ada.Text_IO.Close (F);
   end New_File;

begin
   for I in -1000 .. -1 loop
      New_File (I);
   end loop;
end;

This program creates 1000 files with names "temp/-1000.txt",
"temp/-999.txt", etc. (I use negative counters because I don't want to
waste my time with that useless space in front of the image of
positive integer value).
If the File_Type has finalization, then this program is expected to
finish correctly without the Close call (uncommented above).
On my computer it fails with USE_ERROR after creating 253 files. If we
add the three standard I/O streams, we get a reasonable assumption
that the program has hit an implementation limit (256?) of open file
descriptors.
If I uncomment the Close call, the program properly creates full 1000
set of files.
I expect Close to be called automatically as part of finalization.

So - is it the implementation (GNAT) bug?

Or maybe the finalization is concerned with memory management only
(buffers, etc.) and not with external resources? In that case I
consider it a bug in AARM.

--
Maciej Sobczak * www.msobczak.com * www.inspirel.com

Re: Files and controlled types

[Adam Beneschan]

On Mar 9, 6:27 am, Maciej Sobczak <see.my.homep...@gmail.com> wrote:
> On 9 Mar, 04:12, "Jeffrey R. Carter" <spam.jrcarter....@spam.acm.org>
> wrote:
>
> > > File types are not Controlled.
> > > What is the rationale for this?
>
> > What makes you think they're not controlled.
>
> a) AARM
> b) trivial test
>
> > The ARM only gives the public view,
> > which is limited private; there's nothing to prevent the full view from being
> > controlled.
>
> There is nothing that mandates it and therefore I have to assume it is
> not done. This is actually what I see in tests.
>
> > In addition, the descriptions of Ada.Sequential_IO, Ada.Direct_IO,
> > and Ada.Text_IO all include the language "The type File_Type needs finalization
> > (see 7.6)".
>
> This is very good - I haven't notice it.
> It is very good, because then instead of broken library definition we
> can talk about implementation bugs - these are easier to fix.
>
> My little test follows:
>
> with Ada.Text_IO;
> procedure A is
>
>    procedure New_File (I : in Integer) is
>       Name : String := "temp/" & Integer'Image (I) & ".txt";
>       F : Ada.Text_IO.File_Type;
>    begin
>       Ada.Text_IO.Put_Line ("Opening " & Name);
>       Ada.Text_IO.Create (F, Ada.Text_IO.Out_File, Name);
> --      Ada.Text_IO.Close (F);
>    end New_File;
>
> begin
>    for I in -1000 .. -1 loop
>       New_File (I);
>    end loop;
> end;
>
> This program creates 1000 files with names "temp/-1000.txt",
> "temp/-999.txt", etc. (I use negative counters because I don't want to
> waste my time with that useless space in front of the image of
> positive integer value).
> If the File_Type has finalization, then this program is expected to
> finish correctly without the Close call (uncommented above).
> On my computer it fails with USE_ERROR after creating 253 files. If we
> add the three standard I/O streams, we get a reasonable assumption
> that the program has hit an implementation limit (256?) of open file
> descriptors.
> If I uncomment the Close call, the program properly creates full 1000
> set of files.
> I expect Close to be called automatically as part of finalization.

I'm not so sure.  What happens here?

    procedure New_File (I : in Integer) is
       Name : String := "temp/" & Integer'Image (I) & ".txt";
       F : Ada.Text_IO.File_Type;
    begin
       Ada.Text_IO.Put_Line ("Opening " & Name);
       Ada.Text_IO.Create (F, Ada.Text_IO.Out_File, Name);
       Ada.Text_IO.Set_Output (F);
    end New_File;

    procedure Proc is
    begin
       New_File (-17);
       Ada.Text_IO.Put_Line ("This is written to default output");
    end Proc;

New_File will set the current default output file to File.  When Proc
calls Put_Line, will it then write to that default output file, or
will Put_Line raise an exception or be erroneous?  I'm not 100% clear
on this.  Another question is, what do we (as language designers)
*want* it to do, or what should it do?

But in any case, I haven't seen anywhere in the RM that says that
finalizing a File_Type object involves closing it.  And examples like
this, involving default files or File_Access, show that perhaps you
don't *want* files to be closed when File_Type objects are finalized.
(The RM phrase that says a File_Type "needs finalization" is, I'm
afraid, a smokescreen; this clause has *no* impact whatsoever unless
you have a "pragma Restrictions(No_Nested_Finalization)" in effect,
which would make it illegal to declare certain File_Type objects.  See
AI95-360, http://www.ada-auth.org/cgi-bin/cvsweb.cgi/AIs/AI-00360.TXT?rev=1.11
.
This clause doesn't have any effect on the semantics.)

The bottom line is that things just aren't so simple, and it's not
obvious whether a File_Type "should" cause a Close when the File_Type
is finalized.

                               -- Adam

Re: Files and controlled types

[Maciej Sobczak]

On 10 Mar, 16:37, Adam Beneschan <a...@irvine.com> wrote:

> I'm not so sure.  What happens here?
>
>     procedure New_File (I : in Integer) is
>        Name : String := "temp/" & Integer'Image (I) & ".txt";
>        F : Ada.Text_IO.File_Type;
>     begin
>        Ada.Text_IO.Put_Line ("Opening " & Name);
>        Ada.Text_IO.Create (F, Ada.Text_IO.Out_File, Name);
>        Ada.Text_IO.Set_Output (F);
>     end New_File;
>
>     procedure Proc is
>     begin
>        New_File (-17);
>        Ada.Text_IO.Put_Line ("This is written to default output");
>     end Proc;

I will describe what I expect it to do (instead of guessing around the
AARM).

The F object in New_File, when going out of scope, is finalized and it
is when it is discovered that the file reference was "leaked" outside.
The exception is raised at this point.

Now consider the following extension to the library and the change in
behavior:

Ada.Text_IO.Set_Output (Ada.Text_IO.Release (F));

where Release is a hypothetical function that removes the ownership
from F and is used *exactly* to transfer the resource to other
managing object. Then, the F is finalized but this has no effect (F is
no longer an owner of the resource).
Note that Release can return a type that is different from File_Type
to actually enforce this protocol at compile time (no way to pass F
directly to Set_Output).

> The bottom line is that things just aren't so simple, and it's not
> obvious whether a File_Type "should" cause a Close when the File_Type
> is finalized.

From my perspective, this part of the library is half-baked.
Note also that ownership transfer is a very rarely used operation when
compared to regular file usage. I believe that language should make
that more frequent use case more intuitive and idiot-proof at the cost
of making the less frequent use cases more verbose.

--
Maciej Sobczak * www.msobczak.com * www.inspirel.com

Re: Files and controlled types

[gpriv]

On Mar 8, 11:12 pm, "Jeffrey R. Carter"
<spam.jrcarter....@spam.acm.org> wrote:
> Maciej Sobczak wrote:
>
> > File types are not Controlled.
> > What is the rationale for this?
>
> What makes you think they're not controlled. The ARM only gives the public view,
> which is limited private; there's nothing to prevent the full view from being
> controlled. In addition, the descriptions of Ada.Sequential_IO, Ada.Direct_IO,
> and Ada.Text_IO all include the language "The type File_Type needs finalization
> (see 7.6)".

Doesn't it mean that it's user responsibility to close the file?

George

>
> --
> Jeff Carter
> "No one is to stone anyone until I blow this whistle,
> do you understand? Even--and I want to make this
> absolutely clear--even if they do say, 'Jehovah.'"
> Monty Python's Life of Brian
> 74

Re: Files and controlled types

[Eric Hughes]

On Mar 8, 3:22 pm, Maciej Sobczak <see.my.homep...@gmail.com> wrote:
> File types are not Controlled.
[...]
> I would think that types associated with external resources should be
> Controlled to facilitate resource management in the presence of
> exceptions [...]

The current file types are at an analogous abstraction level to the
standard C library.  Ada could also use a file type analogous to that
in the standard C++ library.  Both are relevant.

Eric

Re: Files and controlled types

[Robert A Duff]

Eric Hughes <eric.eh9@gmail.com> writes:

> On Mar 8, 3:22 pm, Maciej Sobczak <see.my.homep...@gmail.com> wrote:
>> File types are not Controlled.
> [...]
>> I would think that types associated with external resources should be
>> Controlled to facilitate resource management in the presence of
>> exceptions [...]
>
> The current file types are at an analogous abstraction level to the
> standard C library.  Ada could also use a file type analogous to that
> in the standard C++ library.  Both are relevant.

True.

Note that Ada's file handling predates finalization.  And Adam Beneschan
showed why it would be hard to "fix" things in an upward compatible way.

It's not hard to write your own file type, so that initialization opens
the file, and finalization closes it.  You can pass the file name as a
discriminant to the File_Type, or (now that Ada supports limited
constructor functions) you can use one or more functions to "construct"
an open file from a name or from whatever else you like.

- Bob