MinGW+pthread 2010.03

この記事は現状、速報です。内容の信憑性と網羅性がいつもに増して怪しいです。

（2010/05/25追記）猫研パックでの対応に関して追記。

MinGW+pthread 2010.03

2010/03/07のmingwrt-3.18でTLS-Callbackがサポートされた関係で、MinGWにおけるpthread-w32の取り扱いが若干入り組んだ状況になっている。

以前に書いていたpthread-w32において、pthread-w32のstatic版を、固有の関数の呼び出しなしに使用する方法を模索したが、これに影響が出ることは間違いない。

猫研がMinGW猫科研究所パックにおいて試した限りでは、ユーザコード中で_tls_used変数を用意してしまうと、libmingwがリンクされる場合にlibmingw内の同じ変数とバッティングしてしまう。つまり、TLS-Callbackを使用する場合にはmingwrt-3.18の意図する方法で行わねばならない。というか、今回の事態には、これで初めて気づいた（猫研パックa006を一瞬掲載したのにすぐ消したのはこのため）。

それだけ書き換えればいいかと思いきや、元々TLS-CallbackサポートのパッチがMinGWに投稿された際のMLの流れを斜め読みすると、（Windows9x系だけの問題なのかよく読んでいないが）GCCや標準ライブラリとも関係が出てきそうで、危険な匂いがする。

仮にこの新しいmingwrtとTLS-Callbackに正しく対応したGCCがリリースされたとして、今度はDLL版のpthread-w32を使用した場合に2重初期化・2重解放などの問題が発生しないかも懸念される。かなり危なっかしい状況と言っていいだろう。

 他に気になる点

他に、pthread-w32のstatic版の問題を解決していた（autostatic版）サイトで、その更新版、pthreads updated again « autobuilds logが出ていた。

これは昨年の話なのでmingwrtの更新とは関係ないはずだが、そのdiffを見たところ、なんとTLS-Callbackを使用していない（！）。これで問題がないとはどういうことなのか。この更新は「Alexander Strangeの提案に基づき」とあるのだが、この人はこの人で、ffmpeg-mt（ffmpegのマルチスレッド対応を強化しているもの）の作者でもあるし、x264にも関わっている人なので、間違ったことをするはずもない。しかし、その「提案」の内容は見つけられなかったので、理屈は良く分からない。

 で。

現在の猫研パックが採用しているTDM版のGCC(gcc-4.4.1-tdm-2)はmingw-3.18以前のものであるため、これに安易にmingwrt-3.18を組み合わせるのは危険だ。GCCや標準ライブラリまで自ビルドすればよいのかもしれないが、そこまで手を出すのは作業量的につらいため、現状では様子見で行きたい。

恐らく、TDM版のGCCが更新する際にはこの新しいmingwrtとTLS-Callbackに対応したものがリリースされるであろうし、そもそもMinGWオフィシャルのGCCが更新されれば問題ないので、それまで待つつもりでいる。

個人的には、pthreadは今やかなり重要度が高いコンポーネントなのだから、オフィシャルのMinGWで問題なく使用できるようにするのが一番よいのだと思う。mingwrtの一部として取り込まれることを望みたい。

と書いていたら、MinGWのオフィシャルで、Proposedにgcc-4.5.0_20100311-2とpthreads-w32-2.8.0-3が出ている。pthreads-w32は2月中の物なので新しいmingwrtに対応しているのか不明だが、今後に期待できる状況にはなってきたようだ。

正直もうpthreadには疲れた。

 その後の猫研パックでの対応

その後、MinGWオフィシャルで動きがないことに痺れを切らせて、猫研パックa006をリリースしてしまった。

この中では変数に対するバッティングのみを解決し、mingwrtのものを使用するようにした。パッチ内では、パッチ側で用意していた部分をコメントアウトし、他はほぼそのままとしている。

x264などで使用しているが、今のところ問題なく動作しているようだ。