Re: Finalization and .NET/deterministic or orderly shutdown

From: Sean Hederman (usemy_at_blogentry.com)
Date: 02/18/05 

Date: Fri, 18 Feb 2005 18:17:55 +0200

"WXS" <WXS@discussions.microsoft.com> wrote in message
news:0B265D2A-4BD4-45D7-A787-ABADC79E08A8@microsoft.com...
> As I said that is the problem for the most part, have you ever seen a
> production worthy application really call dispose and implement a
> disposable
> pattern on every object in the system so these types of things can be
> done? I
> would have to believe the answer is no or very rarely. In that case it
> seems
> .NET is severely lacking in deterministic shutdown to handle these types
> of
> practices.

To be fair, the disposable pattern is only really needed when calling class
contains disposable or unmanaged fields. One place where I've seen problems
is when a class is originally coded without needing IDisposable, all the
code is built up around it, and then the class is changed to require
IDisposable. It's very rare that people actually go back and change all
references to that class to use the IDispose.

One solution to this problem is to do the following for all non-trivial
classes, whether they implement IDisposable or not:
using(new XYZ() as IDisposable) {
}

Doesn't help you with your finalization problem though ;D

> Let's say for example I hold a unmanaged resource so I use a finalizer to
> free it, but there is a problem freeing it. A good programming practice
> is
> to log this to a log file, console output, event log or something. But it
> turns out all of those things have been finalized by the point we got here
> so
> I can't output any diagnostics at all.

True, but if your program is in a situation where the entire Framework is
being finalized, then at the very least it's in an AppDomain shutdown. If
it's a Process shutdown then most of your unmanaged resources will generally
be automatically reclaimed by the OS anyway: memory, file handles, GDI
handles and so forth.

Another thing, I haven't tried this, so I don't know, but the documentation
seems to be a bit vague as to whether AppDomain.DomainUnload is called
before or after finalization starts.

I'd say your best solution if this worries you is aggressive use of
IDisposable. Just because others don't always use it properly doesn't mean
you can't.

> As I said if it were really realistic for everyone to build their own
> object
> disposal mechanisms you would see more applications doing that. I can't
> say
> I've seen a .NET application of any reasonable size handle shutdown for
> everything in such an ordered manner. Given that it seems adding CLR
> features or compiler features would be helpful to help resolve this real
> world concern.
>
>
>
> "Lasse Vågsæther Karlsen" wrote:
>
>> WXS wrote:
>> > Any chance 2.0 will help with this?
>> >
>> > Finalization for .NET really needs the ability to support leaving some
>> > functionality intact until the program actually terminates. There
>> > should be
>> <snip>
>>
>> Finalizers are not deterministic destruction, quite the opposite.
>>
>> Instead, the only present way in .NET to handle this is to specifically
>> call a method on each object to clean it up. The IDisposable pattern is
>> perfect for this sort of thing.
>>
>> A finalizer is there for objects that you just leave hanging in the air
>> without telling them you're finished them. I would say that if you
>> depend on critical shutdown code to run you should not run it in a
>> finalizer.
>>
>> Additionally, a finalizer shouldn't access any objects stored in the
>> object being finalized, as those objects might've been garbage collected
>> previously.
>>
>> --
>> Lasse Vågsæther Karlsen
>> http://www.vkarlsen.no/
>> mailto:lasse@vkarlsen.no
>> PGP KeyID: 0x0270466B
>>

Relevant Pages

  • Re: "using" vs "= null" and object lifetime
    ... IDispose, it doesn't mean that the object doesn't need to be GCed anymore. ... finalizer. ... is meant to be a safeguard if people don't call Dispose. ... The process of having the memory reclaimed ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: About speed
    ... IDisposable needs a finalizer, and most code that I see that implements ... void IDisposable.Dispose ... call GC.SupressFinalizer inside their Dispose method. ... then disposed explicitly (using IDispose), ...
    (borland.public.delphi.non-technical)
  • Re: Question on implementing IDisposable
    ... have dealth with the unmanaged resources and before you take your ... This class does not implement a finalizer ... The overloaded Dispose which takes a bool argument should be made ... Then, the base class can implement IDispose, so ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Finalization and .NET/deterministic or orderly shutdown
    ... In you ctor you call Register, in your Dispose you call Unregister. ... then at the very least it's in an AppDomain shutdown. ... AppDomaindshutdown event I am pretty sure comes before finalization, ... >> references to that class to use the IDispose. ...
    (microsoft.public.dotnet.framework)
  • Re: Finalization and .NET/deterministic or orderly shutdown
    ... production worthy application really call dispose and implement a disposable ... .NET is severely lacking in deterministic shutdown to handle these types of ... Let's say for example I hold a unmanaged resource so I use a finalizer to ... The IDisposable pattern is ...
    (microsoft.public.dotnet.framework)