[Mono-list] RE: [Mono-devel-list] reading a lot of files without closing them

Jonathan Gilbert 2a5gjx302@sneakemail.com
Mon, 12 Jan 2004 02:43:45


However, I still think the original proposition is valid. Proper coding
conventions aside, isn't it reasonable to check if there is anything which
can be disposed in the event of an error such as "No more file handles"?
It's fine to say that people should take care of disposing such objects
themselves, but when you're writing a runtime or a runtime library, you
have to take into account the fact that people can and will abuse features
of the runtime. You have to work harder than those writing code that uses
the runtime to get those people's code to work, and something like this
should be very simple to implement. If the error indicates that the process
is already using its maximum allocation of a given resource, isn't it
reasonable to call System.GC.Collect() and try again once? I understand
that System.GC() is pretty heavy, but isn't it worse to throw an exception
when it would be possible to reclaim an unused resource?

It was also mentioned that "The GC isn't guaranteed to call the finalizer."
I believe this statement to be incorrect. As I understand it, the GC isn't
guaranteed to call the finalizer *during application shutdown*. However, if
you, for instance, force collection and instances of objects with a
finalizer exist without references, then the finalizers WILL be called.
This is guaranteed by the specification. The whole point of finalizers is
to lazily release unmanaged resources *when the program ISN'T terminating*.
It is an unspoken assumption that the operating system will automatically
release those unmanaged resources when the process terminates, which is why
they didn't bother to require finalizers to be called during shutdown. That
said, finalizers should of course be called as a "best effort" during
shutdown, and if I recall correctly, mono already does make this effort
(the main problem being that objects can resurrect themselves from within
the finalizer).

Just my two cents,

Jonathan

..sorry about the poor quality of this writing. It's nearly 3 AM and so my
brain isn't really in the best shape to be contributing :-)

At 02:35 PM 11/01/2004 -0200, A Rafael D Teixeira
rafaelteixeirabr-at-hotmail.com |mono-list  wrote:
>>From: David Sheldon <dave-monolist@earth.li>
>>
>>My code was something like this:
>>
>>try {
>>   XmlValidatingReader xvr = new XmlValidatingReader (new 
>>XmlTextReader(filename));
>>   while(!xvr.EOF)
>>     xvr.Read();
>>   xvr.Close();
>>}
>>catch (XmlSchemaException ex) {
>>   // print error
>>}
>
>Well, commonly it should be coded as below, as the OBLIGATION to close the 
>file is yours, because the finalizer may never be called by the gc, and even 
>when it is called that may be too late anyway...
>
>try {
>   XmlValidatingReader xvr = new XmlValidatingReader (new 
>XmlTextReader(filename));
>   try {
>     while(!xvr.EOF)
>       xvr.Read();
>   } finally {
>     xvr.Close();
>   }
>}
>catch (XmlSchemaException ex) {
>   // print error
>}
>
>But being somewhat (some people say totally) lazy myself, I like to abuse of 
>the 'using' statement, and as you pointed that  XmlValidatingReader doesn't 
>implement IDisposable I just have my handy homegrown subclass:
>
>class DXmlValidatingReader : XmlValidatingReader, IDisposable
>{
>  public DXmlValidatingReader(string FileName) : base(new 
>XmlTextReader(FileName)) {}
>
>  void IDisposable.Dispose() { this.Close(); }
>}
>
>And so the code becomes:
>
>try {
>  using (DXmlValidatingReader xvr = new DXmlValidatingReader (filename) ) {
>    while(!xvr.EOF)
>      xvr.Read();
>  }
>} catch (XmlSchemaException ex) {
>  // print error
>}
>
>Rafael Teixeira
>Brazilian Polymath
>Mono Hacker since 16 Jul 2001
>MonoBrasil Founding Member - Membro Fundador do MonoBrasil
>English Blog: http://monoblog.blogspot.com/
>
>_________________________________________________________________
>MSN Messenger: converse com os seus amigos online.  
>http://messenger.msn.com.br
>
>_______________________________________________
>Mono-devel-list mailing list
>Mono-devel-list@lists.ximian.com
>http://lists.ximian.com/mailman/listinfo/mono-devel-list