[Mono-dev] set culture uses serialization?

Steve Bjorg steveb at mindtouch.com
Sat Jan 5 00:10:57 EST 2008 

This issue and the fact that Korean isn't supported for CultureInfo  
are blockers for a large customer deployment of ours.  Is there any  
way these issues can be addressed?  Who is working on CultureInfo?

- Steve

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


On Jan 3, 2008, at 12:22 PM, Steve Bjorg wrote:

> 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,S 
>>>>>>>>> yst
>>>>>>>>> em
>>>>>>>>> .I
>>>>>>>>> O.BinaryWriter,bool)
>>>>>>>>> <0x0001f>
>>>>>>>>>   at
>>>>>>>>> System.Runtime.Serialization.Formatters.Binary.ObjectWriter.Wr 
>>>>>>>>> ite
>>>>>>>>> Ob
>>>>>>>>> je
>>>>>>>>> ct
>>>>>>>>> (System.IO.BinaryWriter,long,object) <0x0020d>
>>>>>>>>>   at
>>>>>>>>> System.Runtime.Serialization.Formatters.Binary.ObjectWriter.Wr 
>>>>>>>>> ite
>>>>>>>>> Ob
>>>>>>>>> je
>>>>>>>>> ctInstance
>>>>>>>>> (System.IO.BinaryWriter,object,bool) <0x0014c>
>>>>>>>>>   at
>>>>>>>>> System.Runtime.Serialization.Formatters.Binary.ObjectWriter.Wr 
>>>>>>>>> ite
>>>>>>>>> Qu
>>>>>>>>> eu
>>>>>>>>> edObjects
>>>>>>>>> (System.IO.BinaryWriter) <0x0002d>
>>>>>>>>>   at
>>>>>>>>> System.Runtime.Serialization.Formatters.Binary.ObjectWriter.Wr 
>>>>>>>>> ite
>>>>>>>>> Ob
>>>>>>>>> je
>>>>>>>>> ctGraph
>>>>>>>>> (System.IO.BinaryWriter,object,System.Runtime.Remoting.Messagi 
>>>>>>>>> ng.
>>>>>>>>> He
>>>>>>>>> ad
>>>>>>>>> er[])
>>>>>>>>> <0x0003a>
>>>>>>>>>   at
>>>>>>>>> System.Runtime.Serialization.Formatters.Binary.BinaryFormatter 
>>>>>>>>> .Se
>>>>>>>>> ri
>>>>>>>>> al
>>>>>>>>> ize
>>>>>>>>> (System.IO.Stream,object,System.Runtime.Remoting.Messaging.Hea 
>>>>>>>>> der
>>>>>>>>> [])
>>>>>>>>> <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