[Mono-devel-list] Thread.CurrentCulture and appdomains

[Lluis Sanchez]

Hi,

If we move to a setup where mscorlib is always compiled as "shared",
wouldn't this fix all issues? The same Thread and CultureInfo instances
could be shared in all domains, right? (looks like MS.NET does not
support setting a CultureInfo derived class as current culture, at least
crashes for me when doing the cross-domain call).

Lluis.

El ds 30 de 10 del 2004 a les 17:56 +0200, en/na Zoltan Varga va
escriure:
>                                                Hi All,
> 
>   I'm trying to fix
> http://bugzilla.ximian.com/show_bug.cgi?id=50049
> 
> which seems kinda tough, so here are some notes on my current approach:
> 
> Since the Thread object is shared between appdomains, care must be taken in
> the handling of per-thread state, like CurrentCulture. It must satisfy the
> following requirements:
> - Thread.CurrentCulture should always return an object in the current
>   appdomain.
> - If the current culture is changed by setting the CurrentCulture property, 
>   this change should be visible to other appdomains.
> - Changes in the _state_ of the current culture object should also be visible
>   to other appdomains.
> - Appdomain unloading should be handled sensibly (?)
> - User created subclasses of CultureInfo should be supported
> 
> One solution is to create a MarshalByRefObject which would contain the 
> (serializable) current culture object as a field. The code would store an
> ObjectRef to this object in the Thread object, and when getting/setting the
> current culture, it would ask the remoting subsystem to create a transparent
> proxy for this holder object, and read/write its current_culture field. This
> way, remoting would take care of marshalling the culture object between 
> appdomains. This approach has some problems, through:
> - care must be taken when creating/accessing the holder object since the
>   remoting code also makes calls to CurrentCulture, leading to infinite loops
>   etc.
> - Each call to CurrentCulture could potentially cause a cross-appdomain call
>   with significant marshalling, so performance would be suffer.
> - When unloading an appdomain, all holder objects should be examined to see
>   whenever they contain a culture object from the dying appdomain. If so, these
>   should be handled somehow.
> 
> Since getting the current culture occurs far more often then setting/modifying
> it, the per-domain CultureInfo objects could be cached somehow. The problem 
> with this approach is that these caches need to be invalidated if a new culture
> is set or the contents of the culture changes. The former can be detected 
> since it involves a call to Thread:set_CurrentCulture, while the later cannot.
> On solution to this problem is to modify the CurrentCulture class to report
> changes to the Thread (s) that point to it. But user created custom CultureInfo
> subclasses would not be able to do this. Assuming custom subclasses are rarely 
> used, caching could be disabled in this case.
> 
>                           any comments ?
> 
>                                  Zoltan
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list