Re: gcroot<> objects and finalization
"Jochen Kalmbach [MVP]" <nospam-Jochen.Kalmbach@holzma.de> wrote in message
news:#NljU2vSKHA.220@TK2MSFTNGP02.phx.gbl...
Hi Kevin!
Class Managed (C++/CLI) holds a pointer to class Unmanaged (native C++).
Class Unmanaged in turn holds a gcroot< > pointer (to a TcpClient).
On process exit, the finalizer of "Managed" deletes the Unmanaged object.
This is ok.
The destructor of Unmanaged tries to use the gcroot<> object (to perform
a disconnect) and I seem to get an Exception that the gcroot object has
already been disposed (ObjectDisposedException).
If you are called from the finalizer, you must never use any .NET objects!
This is not allowed!
So I suggest you implement a "Dispose" Methode in your unmanaged class.
And I also suggest, you should implement the IDisposable-Pattern in your
managed class.
If the managed class is called from Dispose, then you should also Dispose
other managed classes and delete the unmanaged class.
If you are called from the finalizer, you should *only* delete the
unmanaged class and never ever use or reference managed classes!
So the question really comes down to what assurances exist at process
exit in terms of managed objects held by the gcroot<> template, and
whether they can be assumed to still exist.
Inside a finilizer, you must assume, that any other managed objects does
not exist anymore!
This is because when multiple objects become unreachable during a single GC
cycle, there's no guarantee on which order they will be finalized.
The object in the gcroot is reachable though. Reachability analysis can't
look into the managed class.
The only time reachable objects can be finalized is during appdomain
shutdown, but I think finalization is actually just skipped in that case.
I suspect the TcpClient isn't being finalized at all, but explicitly
disposed in two different places.
Or, does the fact that I have a finalizer indirectly referencing another
managed object (ie. via the native object) mean I am violating the rule
that a finalizer should not refer to other managed objects (which is a
definite no-no in a fully managed environment)
That's a misstatement of the rule. A finalizer should not refer to any
managed objects which aren't independently reachable from a root, because
they could already have been collected. Objects protected against
collection using a static field or C++ gcroot template can be used during
finalization.
__________ Information from ESET NOD32 Antivirus, version of virus signature database 4498 (20091011) __________
The message was checked by ESET NOD32 Antivirus.
http://www.eset.com