¿Por qué es CurrentCulture una propiedad de Thread?

Question

Me parece una opción de diseño extraña que la información cultural actual (CurrentCulture y/o CurrentUICulture) sea una propiedad del hilo en ejecución. Por lo menos, parece que el alcance de tal cosa debería ser un nivel superior, a nivel de proceso.

Pero estas cosas generalmente tienen sentido una vez que escuche la razón. Puede ser esclarecedor descubrir por qué los diseñadores de .NET decidieron que Thread era el lugar correcto para poner esta propiedad.

Answer 1

Para empezar, no fue realmente su elección. Esa decisión se tomó mucho antes de que comenzaran, la cultura es propiedad de un hilo del sistema operativo. Revise los documentos SDK para las funciones API Get/SetThreadLocale() por ejemplo.

eso no explica por completo, se han virtualizado otras funciones del sistema operativo, aunque que éste es muy duro para virtualizar porque muchas API son sensibles a la cultura, especialmente los COM.

La siguiente buena razón es porque cambiar la cultura en todo el proceso es extremadamente difícil de implementar. Es una condición de carrera insoluble. Algún otro subproceso podría estar en medio de datos de formato que tienen afinidad cultural. Mientras que un bloqueo funcionaría para evitar que use propiedades de cultivo tal como está cambiando, puede no evitar que cambie en el medio de una cadena de llamadas de formateo. Les requeriría tomar algún tipo de bloqueo global y mantenerlo mientras dure el trabajo de formateo. El punto muerto es muy probable.

Hay otro aspecto en esto, uno que creo que es el problema real. Está relacionado con la propiedad Thread.ExecutionContext. El marco usa esto para "fluir" el estado del hilo de un hilo a otro. Muy oscuro pero importante para imbuir cosas como el contexto de seguridad en un hilo de trabajo. Hubiera sido ideal si ese contexto también pudiera imbuir la cultura para que pueda estar seguro de que cualquiera de los trabajadores que comience tiene la misma cultura que seleccionó y no el sistema operativo predeterminado.

No, realmente no sé por qué. Probablemente porque la primera razón que di. Eso hace sin embargo, es muy peligroso cambiar la cultura de un hilo. El tipo de errores que pueden causar son muy sutil. Como crear un SortedDictionary con una cadena como la clave en su hilo principal con una cultura predeterminada del sistema no operativo. Luego descubriendo que un hilo de trabajo no puede encontrar cosas de vez en cuando porque las reglas de clasificación de las cuerdas son diferentes.

---

EDIT: hay algo de alivio de este problema en .NET 4.5, es compatible con el nuevo CultureInfo.DefaultThreadCurrentCulture estático y propiedades DefaultThreadCurrentUICulture.

---

EDIT2: culture fluye ahora como se describe en el 4to párrafo en .NET 4.6. Esto debería aliviar todas las preocupaciones.

Answer 2

Los tiradores de las ventanas son ellos mismos sus hilos. Nunca debe usar un identificador de ventana (para una ventana de nivel superior, control secundario, etc.) en el contexto de un hilo diferente porque el código que implementa el manejo de ventanas (GDI) no es seguro para hilos. Como UICulture es específico de ventana, significa que también se define en el nivel de subproceso.

Otros aspectos de la GUI también son específicos de subprocesos, como la ventana activa y el enfoque. Aunque hay una API, no recuerdo el nombre, que se une al contexto de la interfaz de usuario de diferentes hilos de manera que el foco, la ventana activa se comparte entre múltiples subprocesos de la interfaz de usuario.

Answer 3

Tomaré una oportunidad, ¿tal vez porque necesitaría múltiples hilos simultáneos usando una cultura diferente? Si piensa en un sitio web asp.net multilingüe, no desea que el proceso esté vinculado a un idioma ... una solicitud web podría ser EN-US y otra fr-FR.

Answer 4

El CurrentCulture no es más que una referencia a un CultureInfo, por lo que no se perdería demasiado al permitir que se cuelgue del hilo (solo la memoria de una referencia). Al mismo tiempo, se obtiene la posibilidad de permitir a los usuarios controlar de forma precisa la cultura actual por hilo, lo que resulta importante en algunos tipos de aplicaciones.

Una razón para tener este grano fino podría ser más obvio para los usuarios que no hablan inglés de un software moderno. Por mi parte, tengo que cambiar el teclado de Windows regularmente y puedo hacerlo fácilmente con un atajo de teclado global. Tener CultureInfo en el hilo nos permite implementar fácilmente una lógica similar en nuestras aplicaciones .NET sin tener que cambiar esa información por proceso.

Ejemplos de uso que vienen a la mente:

1. que podría querer un acceso directo que cambiaría la cultura en mi programa durante un corto período de tiempo a petición del usuario actual (muchas aplicaciones deben permitir varias usuarios en la misma estación de trabajo y en la misma sesión). Pero ese mismo proceso podría tener que continuar utilizando el CultureInfo predeterminado en la máquina, p. log con siempre el mismo formato de sello de tiempo.

2. Es posible que también tenga una solución de informes que podría volcar los informes de varias sucursales de una empresa global, cada una en su propia cultura. Su diseño estaría menos restringido si pudiera cambiar CultureInfo por hilo.

3. Otra razón sería si usted quiere escribir en un archivo mediante una cultura particular, pero no querría especificar la cultura en sus funciones de escritura (por ejemplo, porque esas funciones ya se han escrito). Entonces puede cambiar esa lógica fácilmente sin cambiarla en otros hilos que pueden estar haciendo un trabajo que necesita la cultura predeterminada.