[ruby-dev:48932] Re: doc/extension.ja.rdoc 査読依頼

On 2015/04/13 18:53, Yugui wrote:
> とりあえず草稿の通り「0で埋めておけ」と書いておくので、仕様が固まったら
> 更新することにしましょう。

　まぁそれで誰も困らないですね。

>     　ところで、
> 
>     > Cの世界で定義されたデータ(構造体)をRubyのオブジェクトとして 取り扱いた
>     い場合がありえます．このような場合はTypedData_XXX 関数群を用いて構造体へ
>     のポインタとRubyのオブジェクトとを互 いに変換できます．
> 
>     　従来の T_DATA の使い方はばっさり削るんですか？　あれはあれで、気楽でい
>     いと思っていましたが。少なくとも、現状は、ふつーの人はあれでもいいんじゃ
>     ない、的な設計で書いています。
> 
> 
> TypedDataも知ってればそんなに難しくないので、この際less safeなData_XXXは
> 非推奨にして段階的になくしてもよいかと思うんですが、どうでしょう。
> 標準添付ライブラリから非Typed版が駆逐されてしまったので、良いサンプルが
> ない、というのもあります。

　less safe というのはどういう意味でしょうか。安全性については、変わらな
いような気がします。

　段階的に非推奨にする、というのは、いいかもしれません。

>     > なお, klassは, Objectや他のクラスではなくData (rb_cData)と いう特別な
>     クラスから派生することが推奨されます．
> 
>     　これは単純に知らなかった（守ったことがない）。
> 
> 
> これはむしろ古いドキュメントより弱めてあります。
> 元々は「Dataから派生せよ」と書いてあったんですが、あまり守られていないし
> undef_allocさえ自前でやれば害はないので「推奨」程度にしました。

　この辺は、最初の設計からそれている可能性があるので、慎重になったほうが
いい気がします。undef_alloc は、なるほど。その辺の説明ってあるんでしたっ
けか。

>     > このフラグを指定すると，ガーベージコレクタはこの構造体が 不要になった
>     場合には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中に他のスレッドが走るのが困るという話だったように
> 思います。

　ああ、Ruby コードが動いてしまう可能性がある、ということでしたか。なる
ほど。だから、オブジェクトの生成なんて言葉が出てくるんですね。この辺表現
案を頂いたら、それも見ることが出来るかと思います。

>     > klassの実装がライトバリアを サポートしていることを示します．このフラグ
>     を指定 するとRubyはklassに対してGCをより効率的に実 行できます． ただし，
>     指定する場合はユーザーはklassのすべての メソッドの実装に適切にライトバリ
>     アを挿入する責 任があります．さもなくばRubyは実行時にクラッシュ する可能
>     性があります．
> 
>     　klass の実装ってよりは、このオブジェクトが～　のほうが良いと思います
>     （原理的には klass == 0 もあり得ますし）。
> 
>     　この辺については、README.EXT の末尾に色々書いたので、リンクさせてもい
>     かもしれません。具体的には、「そんなことするな」と書いています。
> 
>     > Cの構造体の割当とDataオブジェクトの生成を同時に行うマクロと して以下の
>     ものが提供されています．
> 
>     　Data オブジェクトというのは、よく定義された用語でしたっけ（純粋に、知
>     らないのです）。
> 
> 
> DataクラスのインスタンスだからDataオブジェクトなんですが、ちょっと分かり
> づらいですね。
> 実はここは原文のままなんですが、Dataのサブクラスであるのを必須だと主張す
> るのをやめたので、reviseの必要もありそうです。
>  
> コメントありがとうございました。のちほど草稿を更新しますが、まだ何かコメ
> ントがありましたらお知らせください。
> 
> 特に無ければ明日か明後日あたりにコミットしようと思います。

　よろしくお願いします。

-- 
// SASADA Koichi at atdot dot net