Gauche > Archives > 2013/09/02

2013/09/02 03:21:10 UTCaharisu
#
Scm_VMErrorHandlerとScm_VMGuardHandler関数はScm_VMWithErrorHandlerとScm_VMWithGuardHandlerのことですか?
#
もしそうなら、この関数はAplly0が可能なエラーハンドラーと処理本体のオブジェクトが必要になると思うのですが、
#
たとえば単純にC側からC文字列のS式をreadするためにScm_ReadFromCStringを実行したいとすると、上記のエラーハンドリング用関数に渡すためにはread対象の文字列を内包した手続きオブジェクトをわざわざ作らないといけなくなります。
#
これ以外の関数呼び出しも同様ですが、一つの関数を実行するためだけでこの手間はなかなか面倒です。
#
Gaucheをライブラリとして使うという視点からみれば、最終的なエラー処理をGaucheに任せるのではなく外部から操作可能になれば助かります。
#
もう一点。今のデフォルトエラーハンドラはエラーを処理できなかった場合はexitをしてしまうのがなかなか痛いです。音もなくアプリケーションが死んでいくのはなかなか心臓に悪い.;-(
2013/09/02 07:24:31 UTCshiro
#
そうです > 手続きオブジェクト。基本的に、「VMがアクティブでない状態でライブラリ関数を呼び出す」というケースが弱いですね。ただ、exceptionHandlerを置き換えちゃってると、VMがアクティブになってる時のエラー処理で困らないかな? 「VMがインアクティブな場合の処理」をカスタマイズできるようにすればいいのか。
2013/09/02 09:03:21 UTCaharisu
#
>> VMがアクティブになってる時のエラー処理で困らないかな?
#
これは実を言うと結構困ってまして、Gauche関数を実行中、この呼び出しはGaucheの外から入ってきているのか、Gauche側が主体になっているのかわからなくてエラーの振り分けが中途半端になっている箇所が現にあります。
2013/09/02 10:14:58 UTCshiro
#
受け皿となるVMが無い場合、エラーを返す先がわからないわけで、どこかにlongjmpするかexitするかしか選択肢が無いわけですが、今はsetjmpで受けてるのですか?
2013/09/02 11:26:43 UTCaharisu
#
どこから説明するか難しいのですが、外側のプログラムはCではなくC#で書いていて、つまりアプリケーションのエントリポイントは常に.NET上です。
#
そしてエラーを返す場所がないといった時や、.NETとGaucheのどちらに例外を伝えればいいかわからないといった場合には常に.NETレベルの例外を投げています。
#
コールスタックの最後の層は必ず.NETなので、とりあえずこれで大丈夫だろうという考えです。
#
今のところこの方法で困っていないのですが、関数呼び出しの階層の中にGaucheの関数があってその中でGaucheの例外を捕まえようとしていた場合処理が飛ばされてしまうので、そのようなケースが必要になったときhaどうしようかなぁと思っているところです。
2013/09/02 11:32:57 UTCshiro
#
そのとおり、Cレベルでの関数の巻き戻しが挟まってる可能性があるので、一旦Cと.NETの境界までlongjmpして動的環境の巻き戻し処理を行い、その後改めて.NETの例外を投げる必要があります。で、user_eval_innerがそこの処理をしてくれるんですが、自前でそれを書くとなると手間ですね。
#
動的環境のハンドリングだけを行う層を作って、Scm_SafeCall(void (*fn)(void *data)); みたいにワンクッション入れるしかないかなあ。
2013/09/02 11:52:30 UTCaharisu
#
文章を書くためにちゃんと考えてみると、多少面倒でもどうにかしてちゃんと.NET<->Gaucheの例外処理を考えたほうがよさそうですね。
#
後々になって問題になると、影響もでかくなって手のつけようがない状態になる気がしてきた。
#
ただ、常にgauche.hや関連するヘッダに書かれている関数を呼ぶために動的環境に対する処理を挟む必要はないですよね?
#
完全にCレベルだけで完結しているユーティリティ的な関数などはVMが絡まないですし。
2013/09/02 12:08:02 UTCshiro
#
Scm_Memqとかはいちいち保護する必要ないですね。内部的に、エラーを投げ得る関数とそうでない関数があって、動的環境をはさむのは前者のサブセットです。Gauche内部の開発ではこれらの使い分けを意識しているので(たとえばエラーを投げない関数はPOSIX mutexロック中に安全に呼べる、とか)、API仕様としてきちんと分類しておいた方がいいですね。
#
で、VMが走ってない可能性のある環境でエラーを投げ得る関数を呼ぶ時には、エラーを受けるラッパを噛ませることにすると。
2013/09/02 12:13:34 UTCaharisu
#
基本的にはヘッダしか見ない、たまに実装を少しだけ覗くという、Gaucheをプログラミング言語として以外の利用の仕方をしているユーザとしては分類わけや簡単に分類の見分けがつくマークみたいなものがあると非常に便利です。
#
ただ、このような使い方はレアケースだと思うので、基本的にはプログラミング言語であるGaucheが対応しないといけない領域かはわかりませんが。
2013/09/02 12:17:09 UTCshiro
#
組み込みでlibgaucheを使うにはいずれ必要になる話なので、ぼちぼち整備の頃合いかも。