[ruby-dev:48931] Re: doc/extension.ja.rdoc 査読依頼
From:
Yugui <yugui@...>
Date:
2015-04-13 09:53:40 UTC
List:
ruby-dev #48931
On Mon, Apr 13, 2015 at 6:00 PM SASADA Koichi <ko1@atdot.net> wrote: > ドキュメントまとめて頂いて、ありがとうございます。多分、それなりに知っ > ている方じゃ無いかと思うのでコメントさせて頂きます。 > > ちなみに、査読というと審査を想像してしまいますが、コメント募集、程度で > すよね。 > はい。RFCですね。 > > > On 2015/04/12 23:58, Yugui wrote: > > doc/extension.ja.rdoc がTypedData_XXXではなくData_XXXにしか触れていない > > ため,今なお新しい拡張ライブラリがData_XXXで作られ続けています. > > このためドキュメントの当該部分を更新するつもりですが,GCに詳しい方に査読 > > をお願いしたく思います. > > doc/extension.rdoc (English)のほうはjaを元に査読後に作成する予定です. > > > > 草稿は下記にあります.(日本語) > > > > * https://gist.github.com/yugui/87ef6964d8a76794be6f > > > > なお,一点確認したいのですが,rb_data_type_t::parentは利用されていないよ > > うに見えました.この認識は合ってますか? > > まさに、この1点について、仕様が固まっていないためドキュメント化してい > ない、という状態です(仕様化・ドキュメント化しようとして、行動を起こした > ら反論があって止まっている)。 > > https://bugs.ruby-lang.org/issues/10621 > > 議論を進めていなくて恐縮です。 > > この点を避けて仕様化するかどうかは、どなたかに判断を任せたいところです > が...。まぁ、このドキュメントがリリースされるのは今年末までなので、それ > までにははっきりさせたいところです。 > とりあえず草稿の通り「0で埋めておけ」と書いておくので、仕様が固まったら更新することにしましょう。 > ところで、 > > > Cの世界で定義されたデータ(構造体)をRubyのオブジェクトとして 取り扱いた > い場合がありえます.このような場合はTypedData_XXX 関数群を用いて構造体へ > のポインタとRubyのオブジェクトとを互 いに変換できます. > > 従来の T_DATA の使い方はばっさり削るんですか? あれはあれで、気楽でい > いと思っていましたが。少なくとも、現状は、ふつーの人はあれでもいいんじゃ > ない、的な設計で書いています。 > TypedDataも知ってればそんなに難しくないので、この際less safeなData_XXXは非推奨にして段階的になくしてもよいかと思うんですが、どうでしょう。 標準添付ライブラリから非Typed版が駆逐されてしまったので、良いサンプルがない、というのもあります。 > > > なお, klassは, Objectや他のクラスではなくData (rb_cData)と いう特別な > クラスから派生することが推奨されます. > > これは単純に知らなかった(守ったことがない)。 > これはむしろ古いドキュメントより弱めてあります。 元々は「Dataから派生せよ」と書いてあったんですが、あまり守られていないしundef_allocさえ自前でやれば害はないので「推奨」程度にしました。 > > > wrap_struct_nameはこの構造体を識別する名前です.主にエラー メッセージ > に用いられます.特にCやRubyの識別子として有効であ る必要はありません. > > エラーメッセージで出してましたっけ。単に統計情報を取るときに使っていた > 気がします。 > 統計ですね。直します。 > > > このフラグを指定すると,ガーベージコレクタはこの構造体が 不要になった > 場合にはGC中に直ちにdfreeを呼び出します. dfreeが新たにオブジェクトを生 > 成したりRuby内部のロック(GVL) を解放する可能性がない場合はこのフラグを指 > 定できます. > > モチベーションが違うと思います。なんか、さっさと free すると SEGV と > か、まずいことが起こるようなのがあったんじゃないかと思うのですが、すみま > せん、はっきり思い出せない。 > > > dfree を sweep 時ではなく、ファイナライザポイントまで遅延させているの > で、何かそうしないといけない理由があったと思うんですが。ここは、ぱっと答 > えられなくてすみません。なんか、sweep するとき、順番が重要で、とかそうい > う話だっけ(でも、それだと lazy sweep でダメなはずなんだよな)。 > > GVL 内かそうじゃないか、というのは、なるほど、そういう考えもあると思い > ます(実装的には、今のところ必ず GVL 内ではありますが)。 > http://d.hatena.ne.jp/nagachika/20131029/ruby_trunk_changes_43455_43467 これによると、さっさとfreeすると(dfreeを呼ぶと) IOのclose operationのせいでGVLが解放されてGC中に他のスレッドが走るのが困るという話だったように思います。 > あと、dfree が オブジェクトを生成すると、多分 BUG になるんじゃないかな。 > Ack > > > klassの実装がライトバリアを サポートしていることを示します.このフラグ > を指定 するとRubyはklassに対してGCをより効率的に実 行できます. ただし, > 指定する場合はユーザーはklassのすべての メソッドの実装に適切にライトバリ > アを挿入する責 任があります.さもなくばRubyは実行時にクラッシュ する可能 > 性があります. > > klass の実装ってよりは、このオブジェクトが~ のほうが良いと思います > (原理的には klass == 0 もあり得ますし)。 > > この辺については、README.EXT の末尾に色々書いたので、リンクさせてもい > かもしれません。具体的には、「そんなことするな」と書いています。 > > > Cの構造体の割当とDataオブジェクトの生成を同時に行うマクロと して以下の > ものが提供されています. > > Data オブジェクトというのは、よく定義された用語でしたっけ(純粋に、知 > らないのです)。 > DataクラスのインスタンスだからDataオブジェクトなんですが、ちょっと分かりづらいですね。 実はここは原文のままなんですが、Dataのサブクラスであるのを必須だと主張するのをやめたので、reviseの必要もありそうです。 コメントありがとうございました。のちほど草稿を更新しますが、まだ何かコメントがありましたらお知らせください。 特に無ければ明日か明後日あたりにコミットしようと思います。 > > -- > // SASADA Koichi at atdot dot net >