I'm busy getting confused about non-deterministic destruction. In an answer to another question I got the advice that destructors/finalisers (which I assume are the same thing in c#, i.e. the function called ~classname()) are expensive and not required. But looking at this example a destructor is used and from the comment sounds like it may be vital. Anyone got some advice about how this all fits together and should I remove the destructor from my code?
Thanks again.
You should only include a finalizer if you absolutely have to run some cleanup at some point, whether it's performed explicitly or not. In such cases you should always have an explicit way of performing clean-up in a timely manner anyway, and that should suppress finalization anyway, so that "good" clients don't see any performance penalty.
You would normally only need a finalizer if you have a direct handle to unmanaged resources - if you only have a reference to another class which has a handle on the resource (e.g. FileStream) then you should leave it to the other class to have a finalizer.
With the advent of SafeHandle in .NET 2.0, situations where it's worth writing your own finalizer are very rare indeed.
The performance penalty of finalizers is that they make your objects live for longer than they need to: in the first GC cycle where they're otherwise considered eligible for collection, they get put on the finalizer queue - and bumped up to the next generation just like any other object which survives a GC cycle. The finalizer will then run in another thread (at some point) and only then will they be eligible to really be collected. So instead of (say) getting collected in the first gen1 collection, they live on past that until the next gen2 collection, which may be considerably later.