[#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
斉藤です。
[#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:25766] Re: I/O operation differs signal handler
From:
"H.Yamamoto" <ocean@...2.ccsnet.ne.jp>
Date:
2005-02-25 03:08:25 UTC
List:
ruby-dev #25766
山本です。 参考までに、他の処理系ではシグナルの処理を遅延させているようです。 Perl: http://perldoc.jp/docs/perl/5.8.0/perldelta.pod 安全なシグナル シグナルが都合の悪い時にやって来るとPerlの内部状態が改変されてしまうという点で 以前のPerlは壊れやすいものでした。しかし現在のPerlは安全になるまで(between opcodes) シグナルの扱いを引き延ばすようになりました。 この変更は、シグナルがPerlをただちに中断させなくなったため、驚くべき副作用を持って いるかもしれません。現在のPerlは、最初に例えば(sort()のような)内部操作や(I/O操作のような) 外部操作を1つ完了することによって今行っていることを終わらせ、その後にのみ (そして次の操作を開始する前に)受け取ったシグナルを調べます。現在の操作が必ず初めに 終わらせられるので内部状態の改変は無くなりましたが、シグナルが効果を発揮するためには より多くの時間がかかるかもしれません。しかしpotentially blocking operationsからの脱出は 今でも働くはずです。 ////////////////////////// Gauche: http://www.shiro.dreamhost.com/scheme/gauche/man/gauche-refj_127.html シグナルがSchemeプロセスに送られると、それはVM中のキューに入れられます。 VMは「安全なポイント」に達した時にキューを検査し、シグナルが届いていればそれを順に処理します。 (このメカニズムのため、SIGILLのようなシグナルはSchemeレベルでは処理できません。 そのシグナルをキューに入れた後でプロセスが意味のある処理を続行できないからです)。 ////////////////////////// Python: http://www.python.jp/pub/doc_jp/lib/module-signal.html Python のシグナルハンドラは Python のユーザが望む限り非同期で呼び出されますが、 呼び出されるのは Python インタプリタの ``原子的な (atomic)'' 命令実行単位の間です。 従って、 (巨大なサイズのテキストに対する正規表現の一致検索のような) 純粋に C 言語の レベルで実現されている時間のかかる処理中に到着したシグナルは、不定期間遅延する可能性があります。 ////////////////////////// また、 http://www.linux.or.jp/JM/html/LDP_man-pages/man2/signal.2.html 他の場所での処理が任意の箇所で割り込まれるため、ルーチン handler は非常に注意しなければならない。 POSIX には「安全な関数」という概念がある。シグナルが安全でない関数に割り込み、かつ handler が その安全でない関数を呼び出していた場合、その挙動は未定義である。安全な関数は様々な規格に明確に リストされている。 とあり、シグナルハンドラで直接 ruby コードを実行するのは良くないのかもしれません。 # シグナルをキューに入れてメインスレッドで処理すれば、[ruby-dev:25716] の pthread 問題も # プラットフォームに依存しない方法で解決できそうな気がしますが、この方法だと結局 gets が # 返るまで interrupt できない気もします。 # Perl は最後の文で「そんなことはない」と言っているようにもみえますけど・・・