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

On 2015/04/14 10:25, Nobuyoshi Nakada wrote:
> On 2015/04/13 19:17, Yugui wrote:
>>     　この辺は、最初の設計からそれている可能性があるので、慎重になったほうが
>>     いい気がします。undef_alloc は、なるほど。その辺の説明ってあるんでしたっ
>>     けか。
>>
>> むしろDataが長いこと要らない子だったという感じです．
>> undef_allocについては明確に書いておいた方が良さそうなので記述を足しました．
> 
>> Dataから派生しない場合には, 必ずrb_undef_alloc_func(klass) を呼び出してください．
> 
> どちらかと言うと、rb_define_alloc_func()で設定しない限りDataとしては扱
> えないので、こちらのほうが重要でしょう。rb_undef_alloc_func()が必要な
> のは、File::StatやEncodingのようにrubyレベルで直接作れないとかmarshal
> できないとかいう類です。
> 
> また、Dataに関しては事実上Objectと差はないので、消してしまおうという話
> も以前からないでもありません。
> 
　この辺、結局どうなりましょうか。よくわかんないけど、Data でも
rb_define_alloc_func() はいるんですよね？

　いつの間にかコミットされたものは


> 
> +なお, klassは, Objectや他のクラスではなくData (rb_cData)とい
> +う特別なクラスから派生することが推奨されます．
> 
> +Dataから派生しない場合には, 必ずrb_undef_alloc_func(klass)
> +を呼び出してください．

となっていますが、この点から問題があるのでは。


　ついでに、コミットへの突っ込みですが、


> 
> +を保持するときには, dmarkではrb_gc_markなどを用いて構造体内
> +のすべての参照をマークしなければなりません．
> 
> +そのような参照を含まない時には0を指定します．
> 
>  
>  # そのような参照は勧められません．

　どういう意味？


> 
> +dsizeは構造体が消費しているメモリのバイト数を返す関数です．
> 
> +引数として構造体へのポインタが渡されます．実装困難であれば0
> +を渡しても差し支えありませんが, できるだけ指定するようにして
> 
> +ください．

　何に使われるか書いた方がいいのではないでしょうか。


> 
> +  このフラグを指定すると，ガーベージコレクタはこの構造体が不
> +  要になった場合にはGC中に直ちにdfreeを呼び出します．
> 
> +  dfreeがRuby内部のロック(GVL)を解放する可能性がない場合はこ
> +  のフラグを指定できます．

　ここ、結局 GVL の話にするんでしょうか。根本的には、違うと思うのですが。

> +ここではdbmdata構造体へのポインタをDataにカプセル化してい
>  ます．DBM*を直接カプセル化しないのはclose()した時の処理を考
>  えてのことです．

　結局、Data というのは残しますか。


　あと、typeddata 関係の、その他の関数・マクロも紹介したほうが良いように
思います。って section が違うんだっけ。



-- 
// SASADA Koichi at atdot dot net