Gauche > Archives > 2010/04/03

2010/04/03 08:09:20 UTCkenhys
#
あ、そうだ。
#
斎藤さんの環境でMinGW/pthread対応版はext/threadsのthread-status 'terminatedのテストをpassしますか?
2010/04/03 08:54:21 UTCshiro
#
PLT Schemeにfutureと
#
touchが入ったのか。でも実装を良く知らないと思うように並列化するのは面倒そうに見えてしまうのだが… http://docs.plt-scheme.org/guide/performance.html?q=future#(part._effective-futures)
2010/04/03 10:03:18 UTC齊藤
#
私の環境ではパスしません。 そこで停止して次へ進みません。 < terminated
#
が、 make check ではなく gosh test.scm でテストを走らせるとパスしてしまうときもあるという状況です。
#
にちゃんねるでもマシンによって再現したとかしなかったとかいう話が出てたので、ちょっとしたタイミングの差なんだと思います。 スレッド関連ではありがちですが…。
#
どういうわけか私の環境だと make check だと何度やってもそこで停止しちゃうんですよ。 なんなんでしょうねぇ。
2010/04/03 10:24:33 UTCshiro
#
そこはpthread_cancel()を呼んでるんですが、pthreads-win32のpthread_cancelって完全に実装されてましたっけ?
2010/04/03 10:55:00 UTC齊藤
#
http://sourceware.org/pthreads-win32/manual/pthread_cancel.html
#
Bugs に書いてあるのがそれでしょうか。
#
POSIX だといくつかの関数が cancellation points になることになってるのが Windows ではそうではない、ってことかな。
#
私は英語わかんない人なのでいいかげんな理解です…。
2010/04/03 11:06:20 UTCshiro
#
あ、それじゃないかな。terminateのテストはひとつのスレッドをsys-nanosleep(windowsではSleep()でエミュレート)をかませた無限ループにしといて、別スレッドからpthread_cancelを送ってるんですが、Sleep()中にcancelのテストが無ければ終了しませんね。
#
あれ、待てよ、sys-nanosleepのエミュレーションをwindowsに入れたのは0.9の後だな。これはsvn trunkの話だと思っていいですか?
#
とりあえずのworkaroundとして、pthread_testcancel()の呼び出しをsrc/system.cのnanosleep()の定義中のSleep()の呼び出しの直後(2箇所)に入れてみるとどうでしょう。このBugsが問題なら、とりあえずそれでこのテストは通るんじゃないかな。
#
ただ、根本的な解決ではありませんが。
2010/04/03 11:14:58 UTC齊藤
#
trunk での話です。
#
早速やってみます。
2010/04/03 11:22:18 UTC齊藤
#
テストにパスしました。
#
何度やってもちゃんとパスします。
#
ちゃんと解決しようと思うとキャンセルポイント埋め込みまくりになるんだろうか…。
2010/04/03 11:23:49 UTCshiro
#
いえ、今回の場合はsleepしているのが0.1秒なのでtestcancel()に引っかかりますが、完全にブロックしちゃうようなシステムコールだとtestcancel()さえ呼ばれないので対応できません。
#
どうしても対応しようとしたら、Bugsの項に挙げてあるように全てのblocking system callの前後でcancel modeを切り替えるしかないでしょう。
#
私としては、pthread-win32に依存するよりもWindowsスレッドを直接使えた方がいいので、そっちの方向で考えたいと思っています。
#
ただ、boehm gc 7.1のmingw版はwindows threadでは動かないので、7.2alphaで試してみようとしてるところで止まってます。
2010/04/03 11:28:36 UTC齊藤
#
なるほど。
2010/04/03 11:29:38 UTCshiro
#
ただ、windows threadでもcancellationは問題になりそうな気がしてるんですよね…
#
たぶんシステムコール全てに渡って、キャンセル用イベントと結果受け取りの両方を待つようなコーディングをしないとならないんじゃないかと思ってます。
#
そしたら、全システムコールの前後にsetcanceltype()を入れるのも大して手間は変わらないかもしれません。
2010/04/03 11:35:29 UTC齊藤
#
拡張を書くときもそのルールが必要になるのだとすればちょっとやっかいかも。