[#25636] [Oniguruma 3.X] reggnu.c — "K.Kosako" <sndgk393@...>
さっき気がついたのですが、元々は
15 messages
2005/02/05
[#25639] Re: [Oniguruma 3.X] reggnu.c
— Yukihiro Matsumoto <matz@...>
2005/02/05
まつもと ゆきひろです
[#25643] Re: [Oniguruma 3.X] reggnu.c
— "K.Kosako" <sndgk393@...>
2005/02/06
Yukihiro Matsumotoさんの
[#25702] Re: [Oniguruma 3.X] reggnu.c
— Kazuo Saito <ksaito@...>
2005/02/15
斉藤です。
[#25705] Re: [Oniguruma 3.X] reggnu.c
— "K.Kosako" <sndgk393@...>
2005/02/16
Kazuo Saito wrote:
[#25647] C level set_trace_func — Shugo Maeda <shugo@...>
前田です。
10 messages
2005/02/07
[#25696] Re: C level set_trace_func
— Yukihiro Matsumoto <matz@...>
2005/02/14
まつもと ゆきひろです
[#25697] Re: C level set_trace_func
— Shugo Maeda <shugo@...>
2005/02/14
前田です。
[#25655] openssl binding for SSL_CTX_set_default_verify_paths and X509_STORE_set_default_paths — Tanaka Akira <akr@...17n.org>
open-uri で https を扱うことを考えていろいろと調べていた所、openssl で、
9 messages
2005/02/08
[#25670] Re: openssl binding for SSL_CTX_set_default_verify_paths and X509_STORE_set_default_paths
— GOTOU Yuuzou <gotoyuzo@...>
2005/02/10
In message <876513vce0.fsf@serein.a02.aist.go.jp>,
[#25683] Re: openssl binding for SSL_CTX_set_default_verify_paths and X509_STORE_set_default_paths
— Tanaka Akira <akr@...17n.org>
2005/02/12
In article <20050211.053825.291449071.gotoyuzo@sawara.does.notwork.org>,
[#25684] Re: openssl binding for SSL_CTX_set_default_verify_paths and X509_STORE_set_default_paths
— Tanaka Akira <akr@...17n.org>
2005/02/12
In article <87psz6gcfh.fsf@serein.a02.aist.go.jp>,
[#25690] Re: openssl binding for SSL_CTX_set_default_verify_paths and X509_STORE_set_default_paths
— GOTOU Yuuzou <gotoyuzo@...>
2005/02/12
In message <87ll9thnng.fsf@serein.a02.aist.go.jp>,
[#25691] Re: openssl binding for SSL_CTX_set_default_verify_paths and X509_STORE_set_default_paths
— Tanaka Akira <akr@...17n.org>
2005/02/12
In article <20050213.021305.304099822.gotoyuzo@sawara.does.notwork.org>,
[#25700] BUG on thread and block? — sheepman <sheepman@...>
こんばんは、sheepman です。
2 messages
2005/02/15
[#25712] core dump with GC in rb_thread_save_context — Tanaka Akira <akr@...17n.org>
昨日の夜からとあるプログラム (五月雨) が 4回ばかり core を吐いていて、
5 messages
2005/02/17
[#25713] pthread trouble on sighandler — Hidetoshi NAGAI <nagai@...>
永井@知能．九工大です．
17 messages
2005/02/18
[#25714] Re: pthread trouble on sighandler
— Yukihiro Matsumoto <matz@...>
2005/02/18
まつもと ゆきひろです
[#25715] Re: pthread trouble on sighandler
— Hidetoshi NAGAI <nagai@...>
2005/02/18
永井@知能．九工大です．
[#25717] Re: pthread trouble on sighandler
— Yukihiro Matsumoto <matz@...>
2005/02/18
まつもと ゆきひろです
[#25719] Re: pthread trouble on sighandler
— Hidetoshi NAGAI <nagai@...>
2005/02/18
永井@知能．九工大です．
[#25726] named capture — Kazuhiro NISHIYAMA <zn@...>
西山和広です。
6 messages
2005/02/19
[#25741] Oniguruma 3.7.0 — Kazuo Saito <ksaito@...>
斉藤です。
7 messages
2005/02/21
[#25755] I/O operation differs signal handler — Minero Aoki <aamine@...>
青木です。
14 messages
2005/02/24
[#25756] Re: I/O operation differs signal handler
— Tanaka Akira <akr@...17n.org>
2005/02/24
In article <20050224091450P.aamine@loveruby.net>,
[#25758] Re: I/O operation differs signal handler
— Tanaka Akira <akr@...17n.org>
2005/02/24
In article <1109213650.235317.11155.nullmailer@x31.priv.netlab.jp>,
[#25759] Re: I/O operation differs signal handler
— Yukihiro Matsumoto <matz@...>
2005/02/24
まつもと ゆきひろです
[#25760] Re: I/O operation differs signal handler
— Tanaka Akira <akr@...17n.org>
2005/02/24
In article <1109224128.668484.13752.nullmailer@x31.priv.netlab.jp>,
[ruby-dev:25758] Re: I/O operation differs signal handler
From:
Tanaka Akira <akr@...17n.org>
Date:
2005-02-24 05:12:09 UTC
List:
ruby-dev #25758
In article <1109213650.235317.11155.nullmailer@x31.priv.netlab.jp>, Yukihiro Matsumoto <matz@ruby-lang.org> writes: > その指摘の意味は「そのあとの展開でこのリビジョン(1.55)の変更 > は不要になっているはず」が真実でないという意味でしょうか。そ > れとも、また別の意味？ [ruby-dev:25003] の callcc への対処としては不要になっていますが、他の 問題を防ぐのに有用にもなり得るという意味です。 ここでいう「他の問題」というのは I/O に signal がからんだときのデータ の蒸発と重複です。 TRAP_BEG, read/write, TRAP_END の順で実行している最中に signal が到着 した場合、タイミングとしては以下の 4通りが考えられます。 (1) read/write が起動する前 (2) read/write の起動中、まだデータが転送されていないとき (3) read/write の起動中、1byte 以上データが転送されたとき (4) read/write が終了した後 ここで、(3), (4) の状況で signal が届いた場合、データの転送が既に行わ れているため、IO バッファの状態を更新すべきです。しかし、signal handler から ruby コードを直接実行すると、その更新が行われないままに動 作するので、read で読んだものが読まれていないとか、write で書いたもの が書かれていないなど、一貫性が成り立っていない状態で動作することになり ます。そのコードが IO オペレーションを行わなければいいのですが、行うと 変なことが起こります。 実の所、現在の実装では TRAP_END の後に IO バッファの状態を更新している ため更新の前に trap が起動するので、上記の問題は残っているのですが、こ れは TRAP_END の前に更新するようにすれば修正できます。 しかし、signal handler から ruby コードが直接実行されると、直しようが なくなってしまいます。 なお、更新のためには read/write の返値が必要なので、signal handler の 中で更新することはできません。また、longjmp も返値が得られないので駄目 です。SA_RESTART を一時的に抜くのはありかもしれませんが毎回やるのはオー バーヘッドが気になり、さりとてずっとそうしておくのは他のライブラリの迷 惑になります。あと、select で待つのは race condition があります。そし て nonblocking は fd を他のプロセスと共有していると迷惑になります。 まぁ、sigsafe を使うかそれと同様なことができれば一番いいのですが、これ はポータブルには出来そうにありません。 http://www.slamb.org/projects/sigsafe/ というように、なかなかいい方法が見つからないのですが、なんかないですか ね? -- [田中 哲][たなか あきら][Tanaka Akira]