[Mono-bugs] [Bug 65414][Nor] Changed - [PATCH] Thread Local Data Slots do not survive nested appdomain transitions

[bugzilla-daemon@bugzilla.ximian.com]

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 lupus@ximian.com.

http://bugzilla.ximian.com/show_bug.cgi?id=65414

--- shadow/65414	2004-09-08 08:49:24.000000000 -0400
+++ shadow/65414.tmp.27486	2004-09-08 10:05:55.000000000 -0400
@@ -231,6 +231,46 @@
 Hashtable in terms of the amount of GC'd memory.
 
 I really do not want to rely on us switching to the Thread-is-per-
 domain model. That model seems to create a plethora of differences 
 with the behavior of the MS framework. the MS FX seems to leak a few 
 types of objects (Thread, Type, String, CultureInfo) by design. 
+
+------- Additional Comments From lupus@ximian.com  2004-09-08 10:05 -------
+As I already said: if the thread object is per-domain you can just
+have a field in it. The mapping between thread objects and domain can
+be done with an array or a hashtable in either the thread object or in
+MonoDomain. There is no easy way to do cross-appdomain calls without
+going to unmanaged code at least once and if you think this transition
+has any impact on the performance of said calls, you're very confused
+about what needs to happen (likely you don't know and you didn't measure).
+There is no point in comparing the memory overhead of the hashtable
+and of the threadstatic internal bits: they are unrelated, you can't
+use threadstatic space for each of the LocalDataStoreSlots as you
+suggest, because you can't add them at runtme unless you use Re.Emit.
+The hashtable should be avoided, but it should be replaced with a
+simple object array, with LocalDataStoreSlot holding the index to the
+slot.
+Please do not continue with the implementation details of the MS
+runtime, since it is not useful as you don't understand the details.
+First, Type: if you had read the blogs you pointed to, you'd know that
+only some of the Type (and other reflection *info) objects are
+marshaled by bleed: this depends on a number of factors and assembly
+code can't depend on that behaviour, since it's a policy that can be
+changed.
+As for the Thread object: the only user-visible change is the dubious
+use of lock(threadobject), which is by itself a stupid thing to do and
+expect it to work cross-appdomain: this can be implemented with
+different thread objects per-domain, too, you just have to share the
+syncblock, so it isn't an issue anyway. The same consideration applies
+to the use of lock on strings: it is silly to consider that a
+compatibility breakage. I don't know about CultureInfo, but since the 
+currentculture can be a user-define type, I highly doubt that it is
+allowed to marshal by bleed, so I assume you didn't test before
+mentioning it.
+There is a performance advantage at sharing strings across domains
+(and even Type objects when possible), but this can't currently be
+implemented in mono without extensive changes (like having the corlib
+methods compiled as shared code for a start: with the current code
+that is not going to give much performance advantage as you can surely
+measure, but there are also other changes, like decoupling the static
+data of a class from the MonoVTable).