A Strolling Programmeraka なかだ

またの名を「風まかせ人まかせ力まかせ」日記

T D I A R Y T I M E S % fgrep -i '' *.td2
<< 2006/06/ 1 2 3 4 1. コールドベア新気球
5 6 1. 一日専業主夫
2. コマンドラインって何
7 8 9 10 11 1. make test
12 1. rb_protect
2. 反省点
3. Array[1,2,3,]がSyntaxError
13 14 1. rb_protect(2)
15 16 1. Symbol#to_proc が 1.9 に入ったけど、alist 対応じゃなかった件。
17 18 19 20 21 22 23 24 25 26 27 28 1. LLRing
29 1. 眼鏡
30 >>
«前の日記(2006-06-06) 最新 次の日記(2006-06-12)» 編集

2006-06-11 modified at Mon Jun 12 11:38:34 2006

* [ruby] make test

iteratorまわりがボロボロ落ちる。 いくつか直してみたものの、どうも互いに矛盾してるのもあるような気がする。

nil.instance_eval関係は、環境次第でSEGVしたりfalse.bindingといわれたり。

本日のツッコミ(全1件) [ツッコミを入れる]
_ kou (2006-06-12 11:38)

昨日教えてもらったrb_protect()ですが,[BUG]をださないようにするにはrb_protect()を使えばいいというわけではなさそうです.
# Ruby/GLib2のソースをみたらきちんとrb_protect()を使っていました.

私の予想ですが,問題は,
(1) signal_connectしたコールバックがRubyのコンテキスト外(rb_funcall()とかの中で呼ばれるとかではないということ)で呼ばれる
(2) Ruby/GLib2のsignal_connect周りの処理を使っている
ことだと思います.

まず,(1)のために,コールバックを評価しているRubyの評価スタック(?)の一番下にきます.ということで,ここで例外を起こすと,他に例外を処理できるところがなくなるのでSEGVして[BUG]がでます.
ところが,(2)のために,それができなくなっています.というのも,Ruby/GLib2のsignal_connectは普通のコンテキスト内で評価されるという前提なので,例外をあげてしまいます.

ということで,解決策は
(1) signal_connectしたコールバック内では確実にrescueする
(2) Ruby/GLib2のsignal_connectの処理を使いまわさずに,コールバック内で例外があがっても,そこで全て処理をする(エラーメッセージを表示するだけにするとか)
と思います.

今は,(1)の作戦をとっています.

rb_protect()のことを言われたときに,↑のことを思い付いて説明できればよかったのですが,回転が鈍くてそれができませんでした.すいません.

お名前:
E-mail:
コメント:

投稿する前にチェックボックスをチェックしてください

本日のPingbacks(全0件)
本日のリンク元
アンテナ
その他のリンク元
検索

Key fingerprint = 1E69 3ED2 C05B 6BA4 34B2 FC25 478B C08D 2772 58F6