[Mono-devel-list] Thread.CurrentCulture and appdomains
vargaz at gmail.com
Sat Oct 30 11:56:27 EDT 2004
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
- 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