■
バグフィックスに本腰を入れる1週間。
とりあえず.NET 1.xでもバグっていた#51495の大物を退治。2年前からあって、いつやっつけようかと折にふれて気に掛かっていたもので、いつも、長い間待たせてごめんまた急に仕事が入った、とか意味不明なことを思っていた。1日で直っちゃった、まさかね、そんなこと言えない。
ってこんなネタ書いてたら歳がばれるな。
次は1年前の#59545か…。もしかしてこのバグを放置していればxml:idの問題が起きないんじゃないかとか一瞬邪なことを考えてしまったりして。これもともとxmlsecのguruが書いたコードだから、全容は把握していないんだよなぁ。
Thread.CurrentCulture
何でもないプロパティのように見えて、これがかなり複雑な存在だったりする。
事はまず、ThreadのインスタンスがAppDomain間で共有されることに始まる。別のAppDomainにあるスレッドを操作するためには、ThreadインスタンスがAppDomain別に生成されていたら意味がない（理論的には、managed code上ではInternalCallのみでやりくりできるのかもしれないが、現実的には後述の理由もあって出来ない）。
Threadインスタンスが同一であるためには、CurrentCultureプロパティの戻り値も同一であるべきだ。実際そうらしい。そんなわけで、CurrentCultureプロパティの返すCultureInfoは、ドメイン間で共有されるようにInternalCall経由でキャッシュされる。
ところで、CultureInfoのmanaged instanceがあるAppDomain上で破棄されたら、他のAppDomain上でも参照できなくなってしまう、というのでは困る。従って、何らかの方法でsetしたCurrentCultureはmanaged object以外の形で存在してもらわなければならない。で、MonoではBinaryFormatterを使ってこれを保持している。
ただし、CurrentCultureが手動でsetされないうちは、こんなことをしても意味がないので、get_CurrentCulture()で取得されたCultureInfoについては、binary serializationは行わない。
…これを最近僕がやっつけたRegionInfoについても同じようにせなあかんのだけど、軽ーく「やっときますわ」と言ってしまって後からびっくりだったのである。