[ruby-dev:39961] Re: Fwd: [ruby-cvs:33451] Ruby:r26235 (trunk): * trace.h: new file. wraps tracing mechanisms.

> > 今回、まずは非有効時のオーバーヘッドが少ない技術としてdtraceの上に実装してみましたが、
> > dtraceべったりではないので他のメカニズムも実装すれば、configure時に選択可能です。
> > usaさんからwindowsだとETWもありえるという指摘をいただきました。
> > traceやprobeのような一般的な名前はdtraceべったりでなくした結果です。
> 
> 　まず，標準の probe ライブラリとするためには，
> 
> (1) probe の挿入点の妥当性の検証
> (2) probe の挿入点の名前の検証
> (3) 実装方法の検証
> 
> が必要かと思います．(1)〜(3) まで，どれもまだという認識でいいでしょうか．
> 
> 　コミットされないと検証もままならない，という意見があるかと思います．
> 
> 　個人的には，(3) 実装方法に関して，の DTrace 依存が当分外れることはない
> と思うので，標準的な名前になることに違和感があります（私が普段使う環境に
> はないし）．(1)，(2)，および (3) の詳細に関しては，まだよく見てません．
> 
> 　DTrace のサポートを受けることが出来るようにすることは，意味があると思
> います．ただ，それなら (a) DTrace 専用であることを謳う（Win32OLE みたい
> に，専用ぽくする） (b) gem で標準っぽいものを作って試行錯誤し，標準添付
> を狙う，なんて方針もあるんじゃないかと思います．
> 
> 　あと，set_trace_func の挙動が rescue もひっかけるようになってしまって
> 変わってしまったということを IRC で聞きました．この辺の挙動の変更は，今
> 回の話とは直接関係なさそうですから，別途議論したほうがいいのではないで
> しょうか．多分，増えて困る人はあまり居ないと思いますが．

[いつも脱線話しかしない私がここですかさず雑談をば]

Linux関係でtraceまわりをごにょごにょした経験でいうと、(1)は超真剣に議論して
からマージしたほうがよいと思います。probeってAPIになってしまうので、一度
probeを入れてしまうとそのルートが完全に消えてしまうような大規模リファクタリングが
出来なくなるので。

なので、Linuxではトレースデータの使い方を説明させて「いつか使うかも」系は
却下するルールにしていました。なのでprobe入れたい人はPhythonスクリプトを勉強して
一生懸命性能データのPlotスクリプトを開発する羽目になるという・・・