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

[Paolo Molaro]

On 10/30/04 Zoltan Varga wrote:
> 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.

Does the culture propagate to the calling appdomain:
	appdomain1: culture a
	-> appdomain2
		change culture tu b and return
	appdomain1: culture a or b?

Anyway, I think the culture needs to be marshaled when going from
an appdomain to the other. You can take advantage of the IsReadOnly
property to enable the cache.
Thread.CurrentCulture needs to be fast so it's better to shift the cost 
to appdomain transitions.

lupus

-- 
-----------------------------------------------------------------
lupus at debian.org                                     debian/rules
lupus at ximian.com                             Monkeys do it better