[Mono-dev] patches for RegionInfo support

Paolo Molaro lupus at ximian.com
Tue Aug 16 09:29:14 EDT 2005

On 08/16/05 Atsushi Eno wrote:
> >>+typedef struct {
> >>+	const stridx_t name;
> >>+	gint16 region_entry_index;
> >>+} RegionInfoNameEntry;
> >>+
> >>+typedef struct {
> >>+	gint16 lcid;
> >>+	gint16 region_entry_index;
> >
> >It likely makes sense to put region_entry_index inside CultureInfoNameEntry
> >instead of having a separate lookup array.
> Mmm, I need clarification here: do you mean, RegionInfoNameEntry
> could be just replaced by CultureNameInfoEntry ? Then I think yes,
> I just created it because of its name nature.
> If you mean having region_entry_index as a member of
> CultureInfoNameEntry, it is waste of memory, though it is tiny.
> If you mean unifying region name index array into culture name index
> array, then the code could be the same, but it is extra cost of
> lookup, though the cost is tiny here too.
> Any of the above fixes are of course ok for me.

I meant in the last structure quoted, RegionLCIDMap. It seems to map
from a locale id to a region index. If you include the region index into
the CultureInfoEntry you save the duplicated lcid fields.

> >This looks wrong: CurrentRegion sounds like a per-thread value and you're 
> >using
> >a static var which is per-domain. Also, even if using a simple static var 
> >is
> >the right thing, the lock is not needed: the worse that can happe is
> >that we create two identical objects and one gets collected by the GC.
> I also guessed so at first, but there seems no CurrentRegion inside
> a thread unlike CurrentCulture.

Not sure what you mean: the MS documentation is very confused as usual,
but it mentions it's per thread.

> Based on the assumption that CurrentRegion is instantiated per-domain,
> I'm not understanding that one is likely to be collected by the GC
> (well, one could be collected in another domain, but it does not
> sound problematic). I think that without the lock CurrentRegion could
> be different instance in the same domain in a race condition.

If you hit the race, the worse that can happen is that two equivalent region
objects are created and they are both stored in the static var: the last
one will be kept alive and the first one will be collected by the GC.
So there is no issue that needs locking here, IMHO.


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

More information about the Mono-devel-list mailing list