[Mono-dev] set culture uses serialization?

Zoltan Varga vargaz at gmail.com
Thu Jan 3 14:59:01 EST 2008


Hi,

CultureInfo might be inmutable, but its components like
NumberFormatInfo are not.
Also, even if it is inmutable, objects cannot be shared across appdomains, so we
couldn't use the object set by the application in another domain.
We assume that the thread culture is set only rarely, so the
serialization overhead
should not be a problem.

              Zoltan

On Jan 3, 2008 8:37 PM, Steve Bjorg <steveb at mindtouch.com> wrote:
> Well, the application runs in 10 different languages simultaneously.
> So, this is only going to help in a few cases.  In other words, I
> should forget about CurrentCulture and instead use a manual override
> in all my date and number formatting invocations?  That's going to be
> a major pain... :(
>
> Is this how it behaves under .Net as well?  I'm really surprised
> about the behavior since CultureInfo is immutable (afaik).
>
>
> - Steve
>
> ---------------------------------
> Steve G. Bjorg
>
> MindTouch
> 555 W. Beech St.
> Suite 501
> San Diego, CA 92101
>
> 619.795.8459x1106 office
> 619.795.3948 fax
> 425.891.5913 mobile
>
>
>
>
> On Jan 3, 2008, at 11:17 AM, Zoltan Varga wrote:
>
> > You could try calling Thread.CurrentCulture, compare the return
> > value with the
> > culture you want to set, and only call the setter if the two are
> > different.
> >
> >                  Zoltan
> >
> > On Jan 3, 2008 6:40 PM, Steve Bjorg <steveb at mindtouch.com> wrote:
> >> In short, I cannot change the current culture without incurring the
> >> serialization cost, correct?  Or am I missing something?
> >>
> >> - Steve
> >>
> >> --------------
> >> Steve G. Bjorg
> >> http://wiki.mindtouch.com
> >> http://wiki.opengarden.org
> >>
> >>
> >>
> >> On Jan 3, 2008, at 8:48 AM, Zoltan Varga wrote:
> >>
> >>> Because code in other appdomains might call Thread.CurrentCulture
> >>> on the same
> >>> thread object since thread objects are shared between appdomains.
> >>>
> >>>            Zoltan
> >>>
> >>> On Jan 3, 2008 4:30 PM, Steve Bjorg <steveb at mindtouch.com> wrote:
> >>>> Zoltan, thx for response.
> >>>>
> >>>> I can see how serialization applies to app domains, but why
> >>>> would it
> >>>> serialize inside the same app domain?  Isn't CultureInfo an
> >>>> immutable
> >>>> object?
> >>>>
> >>>>
> >>>> - Steve
> >>>>
> >>>> --------------
> >>>> Steve G. Bjorg
> >>>> http://wiki.mindtouch.com
> >>>> http://wiki.opengarden.org
> >>>>
> >>>>
> >>>>
> >>>> On Jan 3, 2008, at 6:49 AM, Zoltan Varga wrote:
> >>>>
> >>>>> Hi,
> >>>>>
> >>>>> The current culture is shared between appdomains so the runtime
> >>>>> stores it in
> >>>>> serialized form.
> >>>>>
> >>>>>                       Zoltan
> >>>>>
> >>>>> On Jan 3, 2008 8:21 AM, Steve Bjorg <steveb at mindtouch.com> wrote:
> >>>>>>
> >>>>>> I ran into the following error today on our system (note: I
> >>>>>> truncated the
> >>>>>> stack for legibility).  The interesting part is in bold (prefixed
> >>>>>> by * in
> >>>>>> case the formatting got lost)
> >>>>>>
> >>>>>>
> >>>>>> Too many heap sections: Increase MAXHINCR or MAX_HEAP_SECTS
> >>>>>> Stacktrace:
> >>>>>>   at (wrapper managed-to-native)
> >>>>>> System.Object.__icall_wrapper_mono_array_new_specific
> >>>>>> (intptr,int)
> >>>>>> <0x00004>
> >>>>>>   at (wrapper managed-to-native)
> >>>>>> System.Object.__icall_wrapper_mono_array_new_specific
> >>>>>> (intptr,int)
> >>>>>> <0xffffffff>
> >>>>>>   at System.IO.MemoryStream.set_Capacity (int) <0x0004c>
> >>>>>>   at System.IO.MemoryStream.Write (byte[],int,int) <0x0007a>
> >>>>>>   at System.IO.BinaryWriter.Write (string) <0x000c8>
> >>>>>>   at GregorianCalendar__TypeMetadata.WriteTypeData
> >>>>>> (System.Runtime.Serialization.Formatters.Binary.ObjectWriter,Syst
> >>>>>> em
> >>>>>> .I
> >>>>>> O.BinaryWriter,bool)
> >>>>>> <0x0001f>
> >>>>>>   at
> >>>>>> System.Runtime.Serialization.Formatters.Binary.ObjectWriter.Write
> >>>>>> Ob
> >>>>>> je
> >>>>>> ct
> >>>>>> (System.IO.BinaryWriter,long,object) <0x0020d>
> >>>>>>   at
> >>>>>> System.Runtime.Serialization.Formatters.Binary.ObjectWriter.Write
> >>>>>> Ob
> >>>>>> je
> >>>>>> ctInstance
> >>>>>> (System.IO.BinaryWriter,object,bool) <0x0014c>
> >>>>>>   at
> >>>>>> System.Runtime.Serialization.Formatters.Binary.ObjectWriter.Write
> >>>>>> Qu
> >>>>>> eu
> >>>>>> edObjects
> >>>>>> (System.IO.BinaryWriter) <0x0002d>
> >>>>>>   at
> >>>>>> System.Runtime.Serialization.Formatters.Binary.ObjectWriter.Write
> >>>>>> Ob
> >>>>>> je
> >>>>>> ctGraph
> >>>>>> (System.IO.BinaryWriter,object,System.Runtime.Remoting.Messaging.
> >>>>>> He
> >>>>>> ad
> >>>>>> er[])
> >>>>>> <0x0003a>
> >>>>>>   at
> >>>>>> System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Se
> >>>>>> ri
> >>>>>> al
> >>>>>> ize
> >>>>>> (System.IO.Stream,object,System.Runtime.Remoting.Messaging.Header
> >>>>>> [])
> >>>>>> <0x00206>
> >>>>>> *  at
> >>>>>> System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Se
> >>>>>> ri
> >>>>>> al
> >>>>>> ize
> >>>>>> (System.IO.Stream,object) <0x00015>
> >>>>>> *  at System.Threading.Thread.set_CurrentUICulture
> >>>>>> (System.Globalization.CultureInfo) <0x00056>
> >>>>>>   at MindTouch.Dream.Task.Execute
> >>>>>> (System.VoidHandler,MindTouch.Dream.TaskBehavior) <0x00093>
> >>>>>>
> >>>>>> The odd thing is that it appears setting the culture invokes the
> >>>>>> serializer!?!  Our async execution framework sets the culture
> >>>>>> for all
> >>>>>> asynchronous operations.  Question is, why is it using
> >>>>>> serialization though?
> >>>>>> Can I avoid this somehow and still set the culture?  Thx.
> >>>>>>
> >>>>>>
> >>>>>> - Steve
> >>>>>>
> >>>>>> --------------
> >>>>>> Steve G. Bjorg
> >>>>>> http://wiki.mindtouch.com
> >>>>>> http://wiki.opengarden.org
> >>>>>>
> >>>>>>
> >>>>>> _______________________________________________
> >>>>>> Mono-devel-list mailing list
> >>>>>> Mono-devel-list at lists.ximian.com
> >>>>>> http://lists.ximian.com/mailman/listinfo/mono-devel-list
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>
> >>>
> >>
> >>
> >
> >
>
>



More information about the Mono-devel-list mailing list