| .NET DotNet Forum Index » Visual C++ Forum » gcroot<> objects and finalization... |
|
Page 1 of 1 |
|
| Author |
Message |
| Kevin Frey... |
 Posted: Sun Oct 11, 2009 5:07 pm |
|
|
|
Guest
|
Hello All,
I have the following scenario:
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.
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).
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. 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)
Thanks
Kevin |
|
|
| Back to top |
|
|
|
| Jochen Kalmbach [MVP]... |
| Posted: Sun Oct 11, 2009 11:33 pm |
|
|
|
Guest
|
Hi Kevin!
Quote: 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.
Quote: 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!
Quote: 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!
Quote: 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)
Exactly.
--
Greetings
Jochen
My blog about Win32 and .NET
http://blog.kalmbachnet.de/ |
|
|
| Back to top |
|
|
|
| Jochen Kalmbach [MVP]... |
| Posted: Mon Oct 12, 2009 12:18 am |
|
|
|
Guest
|
Hi Ben!
Quote: 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.
Yes, it is possible to use "reachable" managed objects... but this is
bad app-design and could lead to object-resurrection...
--
Greetings
Jochen
My blog about Win32 and .NET
http://blog.kalmbachnet.de/ |
|
|
| Back to top |
|
|
|
| Ben Voigt [C++ MVP]... |
| Posted: Mon Oct 12, 2009 10:09 am |
|
|
|
Guest
|
"Jochen Kalmbach [MVP]" <nospam-Jochen.Kalmbach at (no spam) holzma.de> wrote in message
news:#JXmSPwSKHA.220 at (no spam) TK2MSFTNGP02.phx.gbl...
Quote: Hi Ben!
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.
Yes, it is possible to use "reachable" managed objects... but this is bad
app-design and could lead to object-resurrection...
oops, I see the OP is specifically talking about appdomain shutdown, when
the GC starts killing off root-reachable objects.
There's a mechanism specifically for dealing with this:
http://msdn.microsoft.com/en-us/library/system.environment.hasshutdownstarted.aspx
|
|
|
| Back to top |
|
|
|
|
