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

Zoltan Varga vargaz at gmail.com
Sat Oct 30 11:56:27 EDT 2004

                                               Hi All,

  I'm trying to fix

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
- 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
- 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 ?


More information about the Mono-devel-list mailing list