[Mono-dev] set culture uses serialization?

[Zoltan Varga]

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,System
> >>>> .I
> >>>> O.BinaryWriter,bool)
> >>>> <0x0001f>
> >>>>   at
> >>>> System.Runtime.Serialization.Formatters.Binary.ObjectWriter.WriteOb
> >>>> je
> >>>> ct
> >>>> (System.IO.BinaryWriter,long,object) <0x0020d>
> >>>>   at
> >>>> System.Runtime.Serialization.Formatters.Binary.ObjectWriter.WriteOb
> >>>> je
> >>>> ctInstance
> >>>> (System.IO.BinaryWriter,object,bool) <0x0014c>
> >>>>   at
> >>>> System.Runtime.Serialization.Formatters.Binary.ObjectWriter.WriteQu
> >>>> eu
> >>>> edObjects
> >>>> (System.IO.BinaryWriter) <0x0002d>
> >>>>   at
> >>>> System.Runtime.Serialization.Formatters.Binary.ObjectWriter.WriteOb
> >>>> je
> >>>> ctGraph
> >>>> (System.IO.BinaryWriter,object,System.Runtime.Remoting.Messaging.He
> >>>> ad
> >>>> er[])
> >>>> <0x0003a>
> >>>>   at
> >>>> System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Seri
> >>>> al
> >>>> ize
> >>>> (System.IO.Stream,object,System.Runtime.Remoting.Messaging.Header
> >>>> [])
> >>>> <0x00206>
> >>>> *  at
> >>>> System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Seri
> >>>> 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
> >>>>
> >>>>
> >>>
> >>>
> >>
> >>
> >
> >
>
>