#test sigmask, expects hup ==> ok
test sigmask during interrupt handler (default), expects #t ==> ok
test sigmask during interrupt handler (explicit), expects #t ==> ok
test sigmask during interrupt handler (multi/default), expects #t ==> ok
test sigmask during interrupt handler (multi/explicit), expects #t ==> ok
test sigmask during interrupt handler (reentrance), expects boo ==> ok
test sigmask during interrupt handler (multi/reentrance), expects boo ==> ok
test sys-sigwait, expects 1 ==> ok
test sys-sigwait / signal handler restoration, expects foo ==> ok
failed.
discrepancies found. Errors are:
test sigalrm1: expects 14 => got 0
Testing autoload and autoprovide ==============================================
<autoload and implicit generic definition>-------------------------------------
test autoload triggered by implicit generic definition, expects foo1-list ==> ok
test autoload triggered by implicit generic definition, expects foo2-list ==> ok
<autoload and class redefinition check>----------------------------------------
#HEADでテストが失敗しました。systemで止まったのでなんだか変だなーと思ってたら・・・・
#「止まった」というのは、止まったあとほっといたらそのまま続行してこうなったということですか?
#ええ，止まったのでログを覗いてたんですが，ふと見直すとテストが進行していて，テストは失敗したという結果に。
#状況としては，ちょっと某ブラウザゲームが同時に立ち上がってまして，システムに多少の負荷はかかっていたかと。
#シグナルまわりのテストについては以前ここで話題になりましたが、シグナルをSchemeのスレッドではなくパラレルGCのスレッドが受けてしまうことによるdiscrepancyが起こり得ます。上のsigalrmのテストの場合、SIGALRMがgcに横取りされた可能性はありますね。で、なぜ続行したかですが、sys-pauseがGCのシグナルで中段されるケースがありえるかな?
#とりあえずテスト失敗の状態で端末を開いてますが，なにか見るところはあります？
#(less でログを見たくらいです)
#いや、今の段階ではもうできることはないです。多分原因は上記の通りパラレルGCスレッドの問題なのでこちらでfixするまで直らんですね。
#えーと，つまり運が悪いと失敗するということでしょうか？ （同時に何か走らせてるとまずい？
#よく理解してませんが深刻な障害ではなさそうなので，そのまま使っても問題なさそうなら結果オーライなんですけど。
#普通に使う分には特に問題ありません。シグナルを確実に特定のスレッドで受けないと困るという用途では問題が出ますが、Schemeレベルでそういうコードを書く必要に迫られることはほとんどないと思いますし、大体は他の方法の方が確実に解決できます。
#了解しましたです。
Gauche > Archives > 2014/11/02