7

現在のカルチャ情報（CurrentCultureおよび/またはCurrentUICulture）が実行中のスレッドのプロパティであるというのは、奇妙な設計上の選択だと思います。少なくとも、そのようなことの範囲は、プロセスレベルで1レベル上にあるべきであるように思われます。

しかし、これらのことは、論理的根拠を聞いてしまえば、通常は理にかなっています。.NET設計者が、スレッドがこのプロパティを配置するのに適切な場所であると判断した理由を知ることは、啓蒙的かもしれません。

4

4 に答える 4

10

手始めに、それは実際には彼らの選択ではありませんでした。その決定は彼らが始めるずっと前になされました、文化はオペレーティングシステムスレッドの特性です。たとえば、Get / SetThreadLocale（）API関数のSDKドキュメントを確認してください。

それは完全には説明されていません。他のOS機能を仮想化していますが、非常に多くのAPI、特にCOMのAPIは文化に敏感であるため、これを仮想化するのは非常に困難です。

次の正当な理由は、プロセス全体で文化を変えることは非常に難しいためです。解決できない競合状態です。他のスレッドは、カルチャとの親和性があるデータのフォーマットの途中にある可能性があります。ロックは、変更されているときにカルチャプロパティを使用しないようにするために機能しますが、フォーマット呼び出しのチェーンの途中で変更されるのを防ぐことはできません。ある種のグローバルロックを取得し、フォーマットジョブの期間中それを保持する必要があります。デッドロックが発生する可能性が非常に高くなります。

これには別の側面があります。それは本当の問題だと思います。これは、Thread.ExecutionContextプロパティに関連しています。フレームワークはこれを使用して、スレッドの状態をあるスレッドから別のスレッドに「フロー」させます。非常にあいまいですが、セキュリティコンテキストなどをワーカースレッドに組み込むことが重要です。そのコンテキストがカルチャを吹き込むことができれば、オペレーティングシステムのデフォルトではなく、選択した同じカルチャを開始するワーカーのいずれかが確実に使用できるようになるのが理想的でした。

そうではありません、私は本当に理由がわかりません。おそらく私が与えた最初の理由のためです。ただし、スレッドのカルチャを変更することは非常に危険です。発生する可能性のあるバグの種類は非常に微妙です。オペレーティングシステム以外のデフォルトのカルチャを使用して、メインスレッドのキーとして文字列を使用してSortedDictionaryを作成するようなものです。次に、文字列の並べ替えルールが異なるため、ワーカースレッドが時折戻ってくるものを見つけることができないことを発見します。

編集：.NET 4.5ではこの問題がある程度緩和され、新しい静的なCultureInfo.DefaultThreadCurrentCultureプロパティとDefaultThreadCurrentUICultureプロパティがサポートされます。

EDIT2：.NET4.6の4番目の段落で説明されているようにカルチャが流れるようになりました。これにより、すべての懸念が軽減されます。

于 2010-11-14T11:46:34.570 に答える
6

ショットを撮ります-おそらく、異なるカルチャを使用する複数の同時スレッドが必要になるためですか？多言語のasp.netWebサイトについて考える場合、プロセスを1つの言語に結び付けたくないでしょう...Web要求はEN-USと別のfr-FRである可能性があります。

于 2010-11-14T03:37:18.780 に答える
2

CurrentCultureはCultureInfoへの参照にすぎないため、スレッドにハングアップさせることで多くが失われることはありません（1つの参照用のメモリのみ）。同時に、ユーザーがスレッドごとに現在のカルチャを細かく制御できるようにする可能性があります。これは、ある種のアプリケーションでは重要であることがわかります。

これをきめ細かくする理由の1つは、英語を話さない現代のソフトウェアのユーザーにとってより明白かもしれません。私は、Windowsで定期的にキーボードを切り替える必要があり、1つのグローバルキーボードショートカットで簡単に切り替えることができます。スレッドにCultureInfoがあると、プロセスごとにその情報を変更することなく、.NETアプリに同様のロジックを簡単に実装できます。

頭に浮かぶ使用例：

  1. 現在のユーザーの要求に応じて、プログラムの文化を短期間変更するショートカットが必要になる場合があります（多くのアプリケーションでは、同じワークステーションで同じセッションで複数のユーザーを許可する必要があります）。ただし、同じプロセスで、マシンのデフォルトのCultureInfoを引き続き使用して、たとえば常に同じタイムスタンプ形式でログを記録する必要がある場合があります。

  2. また、それぞれ独自の文化を持つグローバル企業の複数の支店のレポートをダンプするレポートソリューションがある場合もあります。スレッドごとにCultureInfoを変更できれば、デザインの制約は少なくなります。

  3. もう1つの理由は、特定のカルチャを使用してファイルに書き込みたいが、書き込み関数でカルチャを指定したくない場合です（たとえば、これらの関数はすでに書き込まれているため）。そうすれば、デフォルトのカルチャを必要とする作業を行っている可能性のある他のスレッドでロジックを変更することなく、そのロジックを簡単に変更できます。

于 2010-11-14T04:22:12.177 に答える
2

ウィンドウハンドル自体はスレッド固有です。ウィンドウ処理（GDI）を実装するコード自体はスレッドセーフではないため、別のスレッドのコンテキストでウィンドウハンドル（トップレベルウィンドウ、子コントロールなど）を使用しないでください。UICultureはウィンドウ固有であるため、スレッドレベルでも定義されるようになります。

アクティブウィンドウやフォーカスなど、その他のGUIの側面もスレッド固有です。APIはありますが、名前を思い出せません。これは、異なるスレッドからのUIコンテキストを結合して、フォーカスされたアクティブなウィンドウが複数のユーザーインターフェイススレッド間で共有されるようにします。

于 2010-11-14T03:36:49.843 に答える