#齊藤さん、ありがとうございました。無事パッチ当てられました。
#Shiroさん、パッチ後のGaucheでも、全く動かない方のPCでは状況は変わりませんでした。他のPCでもテストしてみます。
#ありがとうございます。ということはopen_osfhandleを複数回呼ぶという問題ではないということか。
##こういうツールを使えば read でブロックしているのか API の中でブロックしているのかの切り分けくらいまでは出来ませんか
#あ、 API フックはコンソールアプリには使えないんだった。
#noconsole 版の Gauche ならこのツールで検証できるはずです。
#Windowsで使えるstrace類似ツールも見つけたんですが、うちでは症状が再現しないのでどうにも。
#後はmingwのgdbでブレークポイントをかけるとかですが、いずれにせよlibcの内部に踏み込むことになるので茨の道ですね。類似症例が見つかるといいんですが。
#私の方でも再現しないです。 (Windows7)
#正確にはたまにひっかかることがあるんですが、再現しようと思ってもできない。うちはVista SP2です。
#mingw の gdb が一番正攻法に見えるので、時間作ってやってみます。
#Program received signal SIGINT, Interrupt.
[Switching to Thread 10540.0x2874]
0x76626da7 in NlsUpdateSystemLocale () from C:\Windows\syswow64\kernel32.dll
(gdb)
#実行してみて、止まったところでコントロールCで止めてみました。数回やって毎回同じ所なので、この辺りで止まってそうです。
#止めたときのthread apply all btの結果です。https://gist.github.com/3877198 #Wow64か。これが違いかも。
#gauche.process の run-process 、コマンドをexecしないで単にfork(2)したい場合には使えないんですね。cmd/args の代わりにクロージャを渡したらfork(2)するだけ、とかダメですかね?
#:host 渡せなくなるか...
#クロージャ渡した時は、:host指定するとエラーになるとか(汚いな...)
#scshにはそういう機能があるんですが、Windowsでforkセマンティクスが再現できないことと、複数スレッドが走っているところで安全にforkする手段が無いことから、一貫性のある仕様にするのが難しいです。
#forkではなく「gosh自身を再起動して指定のScheme式を評価する」っていうのができないかなと思ってます。ローカル環境は持ち運べませんが、その時点でロードされてたモジュールは自動的にロードするとか。
#なるほど
#機能から実験しているpreforkサーバで、gauche.processが使えたらなー、と思ったのがきっかけだったのですが。
#s/機能/昨日/
#forkはマルチスレッド時代に扱い辛いので、別の抽象ができないかどうか思案中。f
#最近のサーバの実行モデルは、マルチプロセス(prefork)+ユーザスレッドというのが流行りっぽいので、そういうのをGaucheできれいに書けないか、というのが目下の関心だったりします。
#確かにforkとカーネルスレッドの相性はよろしくないですね。
#部分継続がネイティブ化したので、ユーザスレッドは実装しやすく(かつパフォーマンスも出しやすく)なったと思っているので
#あとは、libev(ent) あたりのバインディングを書けば、けっこういけるんではないかと踏んでいます。
#プロセスプールについてはcontrol.*でサポートしようと思ってて、control.jobはプロセスプールにも使うつもりで準備しました。でも例によって予定段階で止まってる。
#あ、control.job なんてのがあるんですか
#あれ、util.list のドキュメントってなくなっちゃいました?
#全部組み込みになっちゃったのか!!
#util.listが分かれてた理由って純粋に実装の歴史的経緯だけで、使う側からしたら分ける意味がないので統合しちゃいました。
#https://gist.github.com/3878061 control.job の info の和訳です。もしよろしければ。