[#45703] test_advise failure on GNU/Linux — Tanaka Akira <tanaka.akira@...>
今朝、気がついたのですが、手元で test_advise が失敗します。
11 messages
2012/06/05
[#45705] Re: test_advise failure on GNU/Linux
— KOSAKI Motohiro <kosaki.motohiro@...>
2012/06/06
小崎です
[#45790] Re: test_advise failure on GNU/Linux
— KOSAKI Motohiro <kosaki.motohiro@...>
2012/06/22
>> /tmp は tmpfs で、カレントディレクトリは ext3 なのですが、
[#45791] Re: test_advise failure on GNU/Linux
— Tanaka Akira <akr@...>
2012/06/22
2012年6月22日 16:42 KOSAKI Motohiro <[email protected]>:
[#45723] Developers' meeting (7/21) — Yusuke Endoh <mame@...>
Hello, committers
13 messages
2012/06/12
[#45731] Re: Developers' meeting (7/21)
— Yusuke Endoh <mame@...>
2012/06/13
Four seats are now left.
[#45735] [ruby-trunk - Feature #6587][Open] proposal: adding new methods File.rootname and Pathname#rootname — "usa (Usaku NAKAMURA)" <usa@...>
14 messages
2012/06/14
[#45944] [ruby-trunk - Feature #6587] proposal: adding new methods File.rootname and Pathname#rootname
— "matz (Yukihiro Matsumoto)" <matz@...>
2012/07/13
[#45745] Re: [ruby-changes:24028] yugui:r36079 (trunk): Embedding CRuby interpreter without internal headers has been difficult — SASADA Koichi <ko1@...>
見逃していました．
19 messages
2012/06/14
[#45747] Re: [ruby-changes:24028] yugui:r36079 (trunk): Embedding CRuby interpreter without internal headers has been difficult
— Yugui <yugui@...>
2012/06/15
2012/6/15 SASADA Koichi <[email protected]>:
[#45748] Re: [ruby-changes:24028] yugui:r36079 (trunk): Embedding CRuby interpreter without internal headers has been difficult
— SASADA Koichi <ko1@...>
2012/06/15
ささだです．
[#45751] Re: [ruby-changes:24028] yugui:r36079 (trunk): Embedding CRuby interpreter without internal headers has been difficult
— Yugui <yugui@...>
2012/06/15
2012/6/15 SASADA Koichi <[email protected]>:
[#45761] Re: [ruby-changes:24028] yugui:r36079 (trunk): Embedding CRuby interpreter without internal headers has been difficult
— SASADA Koichi <ko1@...>
2012/06/18
ささだです．
[#45786] Re: [ruby-changes:24028] yugui:r36079 (trunk): Embedding CRuby interpreter without internal headers has been difficult
— Yugui <yugui@...>
2012/06/21
2012/6/19 SASADA Koichi <[email protected]>:
[#45749] Re: [ruby-changes:24028] yugui:r36079 (trunk): Embedding CRuby interpreter without internal headers has been difficult
— "U.Nakamura" <usa@...>
2012/06/15
こんにちは、なかむら(う)です。
[#45750] Re: [ruby-changes:24028] yugui:r36079 (trunk): Embedding CRuby interpreter without internal headers has been difficult
— Yugui <yugui@...>
2012/06/15
2012/6/15 U.Nakamura <[email protected]>:
[#45754] Re: [ruby-changes:24028] yugui:r36079 (trunk): Embedding CRuby interpreter without internal headers has been difficult
— Nobuyoshi Nakada <nobu@...>
2012/06/15
なかだです。
[#45769] [ruby-trunk - Bug #6606][Open] default_external encoding and STDOUT and UTF-8 — "shyouhei (Shyouhei Urabe)" <shyouhei@...>
7 messages
2012/06/19
[#45780] Re: [ruby-changes:24083] nobu:r36134 (trunk): process.c: no method calls in async-signal-safe — Tanaka Akira <akr@...>
2012/6/19 nobu <[email protected]>:
3 messages
2012/06/19
[#45794] :new_pgroup and :pgroup option for spawn. — Tanaka Akira <akr@...>
process.c で気がついたのですが、spawn に Windows 用の :new_pgroup というオプションが
12 messages
2012/06/23
[#45800] Re: :new_pgroup and :pgroup option for spawn.
— "U.Nakamura" <usa@...>
2012/06/25
こんにちは、なかむら(う)です。
[#45801] Re: :new_pgroup and :pgroup option for spawn.
— Tanaka Akira <akr@...>
2012/06/25
2012年6月25日 11:27 U.Nakamura <[email protected]>:
[#45802] Re: :new_pgroup and :pgroup option for spawn.
— "U.Nakamura" <usa@...>
2012/06/25
こんにちは、なかむら(う)です。
[#45803] Re: :new_pgroup and :pgroup option for spawn.
— Tanaka Akira <akr@...>
2012/06/25
2012年6月25日 11:52 U.Nakamura <[email protected]>:
[#45804] Re: :new_pgroup and :pgroup option for spawn.
— "U.Nakamura" <usa@...>
2012/06/25
こんにちは、なかむら(う)です。
[#45805] Re: :new_pgroup and :pgroup option for spawn.
— Tanaka Akira <akr@...>
2012/06/25
2012年6月25日 12:13 U.Nakamura <[email protected]>:
[#45806] Re: :new_pgroup and :pgroup option for spawn.
— "U.Nakamura" <usa@...>
2012/06/25
こんにちは、なかむら(う)です。
[#45818] [ruby-trunk - Feature #6643][Open] io.seek(off, :end) — "akr (Akira Tanaka)" <akr@...>
30 messages
2012/06/25
[#45823] Re: [ruby-trunk - Feature #6643][Open] io.seek(off, :end)
— KOSAKI Motohiro <kosaki.motohiro@...>
2012/06/25
(6/25/12 6:32 AM), akr (Akira Tanaka) wrote:
[#45825] Re: [ruby-trunk - Feature #6643][Open] io.seek(off, :end)
— SATOH Fumiyasu <fumiyas@...>
2012/06/25
At Mon, 25 Jun 2012 19:32:06 +0900,
[#45843] Re: [ruby-trunk - Feature #6643][Open] io.seek(off, :end)
— Tanaka Akira <akr@...>
2012/06/25
2012年6月25日 23:37 SATOH Fumiyasu <[email protected]>:
[#46224] [ruby-trunk - Feature #6643] io.seek(off, :end)
— "kou (Kouhei Sutou)" <kou@...>
2012/10/16
[#46226] [ruby-trunk - Feature #6643] io.seek(off, :end)
— "kou (Kouhei Sutou)" <kou@...>
2012/10/17
[#46250] [ruby-trunk - Feature #6643] io.seek(off, :end)
— "kou (Kouhei Sutou)" <kou@...>
2012/10/23
[#45826] Question: Thread#kill doesn't throw Exception — SASADA Koichi <ko1@...>
ささだです．
7 messages
2012/06/25
[#45832] Re: Question: Thread#kill doesn't throw Exception
— KOSAKI Motohiro <kosaki.motohiro@...>
2012/06/25
> さらに突っ込んだ質問：
[#45834] Re: Question: Thread#kill doesn't throw Exception
— SASADA Koichi <ko1@...>
2012/06/25
(2012/06/26 4:25), KOSAKI Motohiro wrote:
[ruby-dev:45827] Re: 非同期割り込みに対する対処案（日本語版）
From:
SASADA Koichi <ko1@...>
Date:
2012-06-25 18:40:45 UTC
List:
ruby-dev #45827
(2012/06/25 20:32), Tanaka Akira wrote:
> まず、SIGINT (^C) で ruby を終了できることはとても重要ですから、
> これについては即座に例外になるべきでしょう。
>
> SIGTERM など他のシグナルも同様だと思います。
>
> それ以外については、100% コンパチブルという話を尊重するなら、
> やはりそれも現状どおり即座に例外なんじゃないでしょうか。
> 尊重しないなら、遅延させるという選択肢もあるかもしれません。
少し考えて見ました．考えた過程のログを書いてみるので，ご意見頂けると幸
いです．
状態としては，やはり先のメールの
0. なるべく頻繁にチェックする（これまで通りの動作）
1. ブロッキング処理のタイミングだけチェックする
2. チェックしない
の３つになるような気がしていますので，ある例外がこれら 3 つのどの状態に
するか，という API を考えてみました．
(a) Thread.interrupt_mask(exception, state) do; end
(b) Thread.interrupt_mask(hash) do; end
state は
:immediate_interruptible
:blocking_interruptible
:uninterruptible
の 3 つのシンボルが指定できるとします．それぞれ，モード 0, 1, 2 にあたる
と考えます．
(a) の形式は，例えば
Thread.interrupt_mask(TimeoutError, :immediate_interruptible) do
# block
end
と指定すると，blcok の中では，TimeoutError で割り込まれたとき，即座に例
外を発生する，という感じです．(b) の形式は，単に {e1 => state1, e2 =>
state2, ...} のように，複数指定出来るとします．
Thread.interrupt_mask(param1) do
Thread.interrupt_mask(param2) do
# block (param1 and param2)
end
end
このように，ネストした場合は，block の実行は param1，param2 の両方の設
定が効くとします．ただし，ある例外についての指定が衝突した場合は，内側
（この場合 param2）の設定が有効だとします．
とりあえず，primitive な API（を考えるネタ）として，網羅していると思う
のですが，もし考え落としておりましたらご指摘下さい（ここが勘違いしていた
ら酷い）．実際に使わせるための API については，名前など，よりよいものが
あるかと思いますが，まずは primitive を．
このとき，デフォルトは互換性 100% の方針ということで，全ての例外が
immediate_interruptible だとします．
begin
# 何か処理
ensure
# リソース解放処理
end
という，よくありそうな処理があったとき，リソース解放処理はなるべくなら解
放されたくない，ただし，^C，もしくは SIGTERM などのシグナルは blocking
処理しそうになった，もしくはしている時は割り込まれるのを許す，という処理
は次の様になるでしょうか．
begin
# 何か処理
ensure
Thread.mask_interrupt(Exception, :uninterruptible) do
# 一度全部割り込み禁止にして
Thread.mask_interrupt(SignalException, :blocking_interruptible) do
# シグナルだけ割り込みを許して
# リソース解放処理
end
end
end
２つ書かないといけないのは，ちょっと冗長かもしれませんね．Hash で渡す
方式では，
begin
# 何か処理
ensure
Thread.mask_interrupt(Exception => uninterruptible,
SignalException, :blocking_interruptible) do
# シグナルだけ割り込みを許して
# リソース解放処理
end
end
となって，ちょっとマシかな？
書いていて，出てきた疑問点です．
(1) シグナルを許すと言っても，SIGUSR1 とかも許していいのかな．
(2) POSIX みたいに，このメソッドは blocking とか，すべてきちんと
書き連ねる必要があるのかな．かなり，無理な気がする
（そもそも，何がどのメソッドを呼び出すかわからない気が）．
(3) ライブラリの至る所でこんなの書かれたらハッシュが大量発生して，
オーバヘッドで大変になったりしないだろうか...．
そもそも，これって多用するんだろうか．
(4) ブロックを持たない Thread.mask_interrupt() は許すべきだろうか．
（意味としては，「この呼び出し以降はこの設定で」，という感じ）
なんとなく，許さない方がいいような気がするんだけど
(5) Thread.mask_interrupt() はネストしたら設定を混ぜていく，としたけど
単に，置き換える，という選択肢もあるのか．こっちのほうが使いやすい？
--
// SASADA Koichi at atdot dot net
// interruptible って単語でいいのかな．スペルチェックにひっかかる．