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

[Zoltan Varga]

                                               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