[#31143] m {|(*,(*)),|} — Tanaka Akira <akr@...>
m {|(*,(*)),|} で SEGV します。
[#31164] ruby_set_current_source remains in intern.h — Masahiro Sakai (酒井政裕) <masahiro.sakai@...>
酒井です。
[#31166] is_ruby_native_thread() — Masahiro Sakai (酒井政裕) <masahiro.sakai@...>
酒井です。
なかだです。
永井@知能.九工大です.
なかだです。
永井@知能.九工大です.
ささだです。
[#31168] 構造体オブジェクトのcloneメソッド呼び出しでメモリリーク発生 — m-ohkubo@... (Mitsuhiko OHKUBO)
大久保といいます。はじめまして。
なかだです。
大久保です。よろしくお願いします。
[#31214] Warning: OpenSSL::PKCS7::PKCS7 is deprecated after Ruby 1.9; use OpenSSL::PKCS7 instead — Kazuhiro NISHIYAMA <zn@...>
西山和広です。
[#31222] trunk: バグを指摘している警告 — pegacorn <subscriber.jp@...>
trunk で -Wall を付けてコンパイルしてみると、バグを指摘している警告が
From: pegacorn <[email protected]>
[#31242] p(65536**(1<<29)) stalls — "Yusuke ENDOH" <mame@...>
遠藤と申します。
[#31244] shift — Tanaka Akira <akr@...>
-O0 で、以下のようにすると SEGV になります。
なかだです。
[#31285] p()#=>[] — eklerni <eklerni@...>
松尾といいます。
[#31292] ParseDate.parsedate("Tuesday, July 6th, 2007, 18:35:20 UTC") — Tanaka Akira <akr@...>
ParseDate のマニュアルにある以下の例を動かすと、示された結果
[#31298] retryの使い方 — eklerni <eklerni@...>
松尾といいます。
ささだです。
松尾です、返信ありがとうございます。
Yuguiといいます。
松尾といいます。
In article <[email protected]>,
Tanaka Akira さんは書きました:
In article <[email protected]>,
Tanaka Akira さんは書きました:
In article <[email protected]>,
松尾です。
ささだです。
From:eklerni
まつもと ゆきひろです
In article <E1ILDTi-0005T6-Be@x31>,
まつもと ゆきひろです
In article <E1ILKn6-0003Nv-0f@x31>,
まつもと ゆきひろです
In article <E1ILVN9-0006xJ-7I@x31>,
In article <E1ILq4x-0002Bs-Lg@x31>,
まつもと ゆきひろです
In article <E1ILweZ-00008I-Tu@x31>,
まつもと ゆきひろです
In article <E1ILyGa-0000ug-Qd@x31>,
まつもと ゆきひろです
In article <E1IM1W9-0001uC-Bz@x31>,
まつもと ゆきひろです
[ruby-dev:31276] Re: is_ruby_native_thread()
永井@知能.九工大です. From: SASADA Koichi <[email protected]> Subject: [ruby-dev:31275] Re: is_ruby_native_thread() Date: Mon, 23 Jul 2007 11:20:40 +0900 Message-ID: <[email protected]> > (1) に有効な方法が思いつかないので、(2) しか無いんじゃないか > なぁ。 > > グローバル変数に linked list か hash へのポインタを加えてあ > げて、アクセスは必ず排他制御する感じのものが。 > > 性能に影響が出るほど利用頻度は高いですか? 一つは,外部ライブラリがその内部ルーチンで native thread を 生成する可能性があるケースです. ruby への call が一切無いことが保証されるならいいのですが, そうでない場合には毎回のチェックを必要とする可能性があります. ある固定スレッドに必ず ruby 呼び出し処理を依頼するという方法も もちろんありますが,効率を考えると,直接呼べる限りは直接呼びたいと 考えるのが人情ですよね. ただ,「毎度のスレッド切り替えに比べれば軽いから (2) でいいじゃん」 って主張もありそうですね. もう一つは,割り込み処理です. 割り込み処理を ruby で登録している場合, 割り込みを受け付けた native thread が ruby を呼べるかどうかを チェックする必要がありますよね? 割り込み処理は少しでも早くに完了させるべきですので, チェックもわずかでも早いに越したことはないはずです. # 現在の 1.9 の signal.c では問題なしということであればごめんなさい. > あと、is_* という名前はあれなので、出来れば rb_ がついたナイ > スな名前になるといいなぁ、とは思います。互換性の点から難しいかな。 これは変更しちゃってもいいと思います. is_ruby_native_thread() でのチェックを必要とするようなライブラリは, 1.9 対応のためには,多分,それなりの量の書き直しを必要とするでしょうから. -- 永井 秀利 (九工大 知能情報) [email protected]