[Mono-bugs] [Bug 65414][Nor] Changed - [PATCH] Thread Local Data Slots do not survive nested appdomain transitions
Wed, 8 Sep 2004 08:00:35 -0400 (EDT)
Please do not reply to this email- if you want to comment on the bug, go to the
URL shown below and enter your comments there.
Changed by email@example.com.
--- shadow/65414 2004-09-07 15:00:04.000000000 -0400
+++ shadow/65414.tmp.25520 2004-09-08 08:00:35.000000000 -0400
@@ -178,6 +178,27 @@
Static fields marked with System.ThreadStaticAttribute are scoped per-
thread per-AppDomain. You get convenient declarative thread-local
storage over and above the normal per-AppDomain cloning of static
+------- Additional Comments From firstname.lastname@example.org 2004-09-08 08:00 -------
+Maybe you're starting to see the overhead of threadstatic: with the
+current implementation what you say is true (I had actually forgotten
+that I did implement that part about per-thread per-domain correctly),
+but this wastes memory and slows down the GC, since it's GC memory.
+What you don't understand is that when we change appdomain, the thread
+object or some of its fields need to be changed.
+The second thing cannot be done safely at this time, because it
+requires the vtable to be domain-indep and this in turn requires
+several changes in many parts of the runtime (as a hack we could also
+swap the vtable field with the thread vtable from the new domain, but
+this may have other consequences). Hence the suggestion that we change
+the thread object on mono_domain_set(), which makes your point moot.
+Also, some of the data there needs to be marshaled or we'd leak
+objects from a domain to the other (which creates the same sort of
+issues of the current thread object being shared).
+Having domain-indep code in the vtable would also mean that access to
+thread-static vars would become slower (unless we do other hacks) than
+the access to a field which would be set correctly once per appdomain
+transition in mono_domain_set().