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
--
-----------------------------------------------------------------
[EMAIL PROTECTED] debian/rules
[EMAIL PROTECTED] Monkeys do it better
_______________________________________________
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
