YamaKen
yamak****@bp*****
2004年 10月 3日 (日) 18:35:45 JST
ヤマケンです。 uimの話でもあるのでAnthy-devにもCc:します。私的にはもうSumikaの 話題もAnthy-devに移行してしまった方がいいんじゃないかと思います がどうでしょうか。 At Sun, 03 Oct 2004 16:37:08 +0900 (JST), yusuk****@cheru***** wrote: > uimでuim-scm.hのAPIの多くがuim_lispの形式でScheme側の > データを取ってこれるようになっているんですが、Scheme > インタプリタのGCが取ってきたデータへの参照を認識しないで、 > 適当なタイミングデータが無効になってしまいます。 > #見逃してしまった私のミスでもあるんですが… > > これのせいでsumikaの動作は極めて不安定になってしまってます。 bug #481の件ですね。田畑さんがこの件でコメントを付けていたのも確 認していたんですが、自分の中でこの件は勝手にuim 0.4.4リリース後 の作業と位置付けて返答と作業の優先度を下げていました。すいません。 私が9月中ごろにuimの開発に復帰して最初にやった作業がGCの実装確認 で、その時点でuim-scm APIにこの欠陥がある事は認識していました。 何も考えずに危険なAPIを設計した事と情報の共有を怠った事をお詫び します。 > uim-scm.hのAPIは今後どうやって行きましょうか？ > > 提案としては > (1)uim-scm.h系のAPIを使うなと書いておく 現状では使っているのはSumikaとuim-shだけだとは思いますが、書いて おきます。 > (2)uim_lispオブジェクトを生成するAPIの使用を早期に > やめてとりあえず、sumikaを安定にする。 > # uim_scm_cons, uim_scm_list?等 > #インタプリタ内のオブジェクトへの参照を取得するAPIは > #とりあえず使う repl_c_string()呼び出し側のstack上にuim_lisp(実態はsiodのLISP)が ある場合が問題ですが、とりあえずはgc_protect()したglobal変数に格 納するなどして回避できないかと考えています。もちろん応急処置とし てですが。 > (3)APIを再設計して切り替える > というステップを踏むのでどうでしょうか？ 以前ちょっと話しましたが、この問題がなかったとしてもuim-scmのよ うにSchemeのプリミティブな関数をCの関数としてexportするという設 計では利用が繁雑すぎるので、S式を直接評価する必要がある時は UIM_EVAL_FSTRING()のように文字列ベースで評価するように変更しよう と考えています。また、外部にuim_lispを直接見せるのも危険なのでや めて値のやり取りはCレベルで行うようにしたいと考えています。 uim-scm APIに変更が入る事でそれに依存しているcustom APIも必然的 に変更の必要がありますが、私としては今回は基本的な枠組の変更は考 えていません。uim-scm APIの変更に追随するぐらいに考えています。 hookの扱いなど設計上の問題点はありますが、本質的な解決は以下のよ うに先延ばしにしたいと思っています。 しばらく後の目論見としては情報の格納/取得/伝播/通知を統合する ustoreという仕組を考えていて、uim_get_*()系の情報取得関数と callbackによる更新通知、custom API, helper protocol, property等 をそれで置き換えたいと考えています。が、これより優先度が高いと見 なしている作業(各IM共通機能の分離と内部実装の隠蔽)がまだあるので、 提案はまだ先になります。ただ、領域のかぶる部分で何か変更を考えて いる人がいるなら先に議論した方がいいと思うので言ってください。 しばらく前に足永さんから「custom APIの改良を考えている」という話 を聞きましたが、どんなレベルの変更でしょうか。私としては将来 ustoreを導入する時(採用されると決まったわけではないですが)に移行 が大変になるような事態は避けたいので、問題点、要求、現在の構想な どをできる範囲で教えてもらえればと思います。 Schemeの実装の話になったのでついでに触れておきますが、現在のsiod では repl_c_string() → callback → repl_c_string() のようにnest した形でrepl_c_string()を呼ぶとGCがおかしくなるため、uimでは callback queueを使ってこれを回避していますが、repl_c_string()の 内部で呼ばれているrepl_driver()の実装をいじって、stack_start_ptr の初期化を最初のrepl_c_string()呼び出し時に限って行う事でこの問 題を回避できるんじゃないかと考えています。実際の検証はまだですが、 repl_c_string()がnested reentrantだとAPIの設計自由度が増すので、 uim-scm API(とcustom API)の改訂時に実験してみようと思っています。 ------------------------------- ヤマケン yamak****@bp*****
