[Mono-dev] Reference queue

[Robert Vesse]

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

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 at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list