On 2012-01-24 02:32, Robert Vesse wrote:
If it is the case that you have unmanaged resources that you need to
clean up that you should really be using the IDisposable interface
and calling Dispose() on the class when you are done with it.
If it is possible for code paths to 'forget' to call Dispose() then
you can include a finalizer as well, if you do this you need to make
sure that when Dispose() is explicitly called you call
GC.SuppressFinalize() on that object so the finalizer can be skipped
Ths MSDN has very comprehensive guidelines on implementing IDisposable
and finalizers correctly:
http://msdn.microsoft.com/en-us/library/system.idisposable.aspx
There is also a simpler guide at
http://msdn.microsoft.com/en-us/library/fs2xkftw.aspx
without using a finalizer, which is enough if you have only managed
resources.
Best Regards, D.
Rob
On Jan 23, 2012, at 4:22 PM, Konrad M. Kruczyński wrote:
Thanks for the answer.
Here is the case: Let's say I have a class which contains some data
in temporary file (for example some kind of cache which should not
stay in memory). I'd like to have this file removed when object of
this class dies. I can implement a finalizer but if I do this,
object will be reclaimed later than it should, also putting
additional pressure on GC. Problems of objects with finalizers
which are not manually invoked are generally known. And this is
scenario where such object can be shared and does not fit into any
kind of using block.
I think that mentioned API can resolve that kind of problems,
because I can set up a callback which deletes temporary file
*after* object's death. Therefore it is processed like any other
object, without being in special collection for disposable
objects.
I think it would bring significant performance gain, especially if
objects are created often and we expect they die soon. It should
be measured, but for that I need some kind of API.
What do you think?
We've thought about exporting such interface, but the maintenance
burden made us back off. This interface has some short-coming and
exposing it to managed code has it's problems. For example, it
doesn't support unregistering. But, if you make your case on why
such a feature would help you, I can look into it.
-- Konrad _______________________________________________
Mono-devel-list mailing list Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
_______________________________________________ Mono-devel-list
mailing list Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
_______________________________________________
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
