[Mono-dev] set culture uses serialization?

Steve Bjorg steveb at mindtouch.com
Thu Jan 3 15:22:29 EST 2008 

Zoltan, thanks again for your quick reply.

That assumption might be true for desktop applications, but not for a  
server which runs a localized application.  Each request is handled  
in the website's configured culture.  The matter is made even worse  
when the server tries to be smart and handle the request by using  
asynchronous operations.  Each completion handler must reset the  
current culture since it it will resume on an arbitrary thread of the  
thread pool.

Maybe I'm going all wrong about this?  What is the recommended  
pattern for running a localized web-application that uses  
asynchronous operations?

- Steve

--------------
Steve G. Bjorg
http://wiki.mindtouch.com
http://wiki.opengarden.org


On Jan 3, 2008, at 11:59 AM, Zoltan Varga wrote:

> 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,Sy 
>>>>>>>> st
>>>>>>>> em
>>>>>>>> .I
>>>>>>>> O.BinaryWriter,bool)
>>>>>>>> <0x0001f>
>>>>>>>>   at
>>>>>>>> System.Runtime.Serialization.Formatters.Binary.ObjectWriter.Wri 
>>>>>>>> te
>>>>>>>> Ob
>>>>>>>> je
>>>>>>>> ct
>>>>>>>> (System.IO.BinaryWriter,long,object) <0x0020d>
>>>>>>>>   at
>>>>>>>> System.Runtime.Serialization.Formatters.Binary.ObjectWriter.Wri 
>>>>>>>> te
>>>>>>>> Ob
>>>>>>>> je
>>>>>>>> ctInstance
>>>>>>>> (System.IO.BinaryWriter,object,bool) <0x0014c>
>>>>>>>>   at
>>>>>>>> System.Runtime.Serialization.Formatters.Binary.ObjectWriter.Wri 
>>>>>>>> te
>>>>>>>> Qu
>>>>>>>> eu
>>>>>>>> edObjects
>>>>>>>> (System.IO.BinaryWriter) <0x0002d>
>>>>>>>>   at
>>>>>>>> System.Runtime.Serialization.Formatters.Binary.ObjectWriter.Wri 
>>>>>>>> te
>>>>>>>> Ob
>>>>>>>> je
>>>>>>>> ctGraph
>>>>>>>> (System.IO.BinaryWriter,object,System.Runtime.Remoting.Messagin 
>>>>>>>> g.
>>>>>>>> He
>>>>>>>> ad
>>>>>>>> er[])
>>>>>>>> <0x0003a>
>>>>>>>>   at
>>>>>>>> System.Runtime.Serialization.Formatters.Binary.BinaryFormatter. 
>>>>>>>> Se
>>>>>>>> ri
>>>>>>>> al
>>>>>>>> ize
>>>>>>>> (System.IO.Stream,object,System.Runtime.Remoting.Messaging.Head 
>>>>>>>> er
>>>>>>>> [])
>>>>>>>> <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