Winでのマルチスレッドバグの可能性を検証する

[koron]

os_win32.c:3564 の mch_system_piped() 内の、3665行目 CreateThread() 呼び出しをみて、ふと気がついた問題。system()をPIPEで実装し、そこへのバッファの書き出しを別スレッドでやっている、ように見える。

問題点の可能性

• 書き出し中にバッファが書き換わる可能性はないか?
• CreateThread() ではなく _beginthreadex() を使わなくて大丈夫か? (ランタイムの適切な初期化)

以上を検証したほうが良い。

現時点で問題が生じていなければさほど気にしなくても良いのですが、可能なら将来の問題の芽は摘みとっておきたいです。

[ynkdir]

書き出し中にバッファが書き換わる可能性

フィルタ実行中に外部から :call remote_expr('GVIM', 'setline("$", "x")') で書き換えできます。

[koron]

まじか…どうすんだコレ…行数を変える系の操作がヤバ気。

[mattn]

すぐその下にループがあってPeekMessage(PM_REMOVE)して捨ててるから大丈夫そうな気がするんだが。

[ynkdir]

そのメッセージループでclient/server通信のメッセージを受信・処理してるので
バッファを読み込んでパイプへ書き込む処理(別スレッド)とremote_expr()で渡された式の実行処理(メインスレッド)が平行して走ります。
ただまあぶっちゃけ誰も困らないと思いますがいまのところ。

[k-takata]

• CreateThread() ではなく _beginthreadex() を使わなくて大丈夫か? (ランタイムの適切な初期化)

スレッドの中で初期化・終了処理が必要なCRT関数を使っていなければ大丈夫でしょうし、CRTにダイナミックリンクしていれば、終了処理は行われるので大丈夫なはずですが、大丈夫か気にするくらいなら _beginthreadex() にしてしまった方がよいのではという気もしますね。
ついでに _beginthread で grep すると if_sniff.c で、_beginthreadex() ではなく _beginthread() を使っているところがありました。戻り値のハンドルを使わないのであれば _beginthread() でも問題ないのですが、使っているようなので _beginthreadex() の方が良いでしょうね。

[koron]

wontfix とします。

誰も困った様子がないので…困ったときになんとかしましょう。

[k-takata]

• CreateThread() ではなく _beginthreadex() を使わなくて大丈夫か? (ランタイムの適切な初期化)

やっぱり気になったのでパッチを投げました。
https://groups.google.com/d/msg/vim_dev/Lx7-yflimq4/kNXrsGXjBgAJ
デフォルトのビルド設定だとCRTはスタティックリンクなので、TLSを使っているCRT関数を使っているとメモリリークしてしまいます。

[k-takata]

7.4.2145
https://groups.google.com/d/msg/vim_dev/Dv8VQY1qELY/4sPXDfT6BgAJ
mingwでwarningが出るらしいので、あとで追加パッチを送付予定。

[k-takata]

7.4.2150
https://groups.google.com/d/topic/vim_dev/Q4SZvTy8vDY/discussion

[k-takata]

• 書き出し中にバッファが書き換わる可能性はないか?

こちらは、困った人がいたらそのときに。