* Files and controlled types @ 2008-03-08 21:22 Maciej Sobczak 2008-03-08 21:56 ` gpriv ` (2 more replies) 0 siblings, 3 replies; 9+ messages in thread From: Maciej Sobczak @ 2008-03-08 21:22 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Files and controlled types 2008-03-08 21:22 Files and controlled types Maciej Sobczak @ 2008-03-08 21:56 ` gpriv 2008-03-09 3:12 ` Jeffrey R. Carter 2008-03-10 15:28 ` Eric Hughes 2 siblings, 0 replies; 9+ messages in thread From: gpriv @ 2008-03-08 21:56 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Files and controlled types 2008-03-08 21:22 Files and controlled types Maciej Sobczak 2008-03-08 21:56 ` gpriv @ 2008-03-09 3:12 ` Jeffrey R. Carter 2008-03-09 13:27 ` Maciej Sobczak 2008-03-09 16:39 ` gpriv 2008-03-10 15:28 ` Eric Hughes 2 siblings, 2 replies; 9+ messages in thread From: Jeffrey R. Carter @ 2008-03-09 3:12 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Files and controlled types 2008-03-09 3:12 ` Jeffrey R. Carter @ 2008-03-09 13:27 ` Maciej Sobczak 2008-03-10 15:37 ` Adam Beneschan 2008-03-09 16:39 ` gpriv 1 sibling, 1 reply; 9+ messages in thread From: Maciej Sobczak @ 2008-03-09 13:27 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Files and controlled types 2008-03-09 13:27 ` Maciej Sobczak @ 2008-03-10 15:37 ` Adam Beneschan 2008-03-10 21:45 ` Maciej Sobczak 0 siblings, 1 reply; 9+ messages in thread From: Adam Beneschan @ 2008-03-10 15:37 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Files and controlled types 2008-03-10 15:37 ` Adam Beneschan @ 2008-03-10 21:45 ` Maciej Sobczak 0 siblings, 0 replies; 9+ messages in thread From: Maciej Sobczak @ 2008-03-10 21:45 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Files and controlled types 2008-03-09 3:12 ` Jeffrey R. Carter 2008-03-09 13:27 ` Maciej Sobczak @ 2008-03-09 16:39 ` gpriv 1 sibling, 0 replies; 9+ messages in thread From: gpriv @ 2008-03-09 16:39 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Files and controlled types 2008-03-08 21:22 Files and controlled types Maciej Sobczak 2008-03-08 21:56 ` gpriv 2008-03-09 3:12 ` Jeffrey R. Carter @ 2008-03-10 15:28 ` Eric Hughes 2008-03-10 22:45 ` Robert A Duff 2 siblings, 1 reply; 9+ messages in thread From: Eric Hughes @ 2008-03-10 15:28 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Files and controlled types 2008-03-10 15:28 ` Eric Hughes @ 2008-03-10 22:45 ` Robert A Duff 0 siblings, 0 replies; 9+ messages in thread From: Robert A Duff @ 2008-03-10 22:45 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2008-03-10 22:45 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2008-03-08 21:22 Files and controlled types Maciej Sobczak 2008-03-08 21:56 ` gpriv 2008-03-09 3:12 ` Jeffrey R. Carter 2008-03-09 13:27 ` Maciej Sobczak 2008-03-10 15:37 ` Adam Beneschan 2008-03-10 21:45 ` Maciej Sobczak 2008-03-09 16:39 ` gpriv 2008-03-10 15:28 ` Eric Hughes 2008-03-10 22:45 ` Robert A Duff
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox