[Mono-dev] Reference queue

[David Schmitt]

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