[#45703] test_advise failure on GNU/Linux — Tanaka Akira <tanaka.akira@...>
今朝、気がついたのですが、手元で test_advise が失敗します。
小崎です
>> /tmp は tmpfs で、カレントディレクトリは ext3 なのですが、
2012年6月22日 16:42 KOSAKI Motohiro <kosaki.motohiro@gmail.com>:
[#45723] Developers' meeting (7/21) — Yusuke Endoh <mame@...>
Hello, committers
Four seats are now left.
[#45735] [ruby-trunk - Feature #6587][Open] proposal: adding new methods File.rootname and Pathname#rootname — "usa (Usaku NAKAMURA)" <usa@...>
[#45745] Re: [ruby-changes:24028] yugui:r36079 (trunk): Embedding CRuby interpreter without internal headers has been difficult — SASADA Koichi <ko1@...>
見逃していました.
2012/6/15 SASADA Koichi <ko1@atdot.net>:
ささだです.
2012/6/15 SASADA Koichi <ko1@atdot.net>:
ささだです.
2012/6/19 SASADA Koichi <ko1@atdot.net>:
こんにちは、なかむら(う)です。
2012/6/15 U.Nakamura <usa@garbagecollect.jp>:
なかだです。
[#45769] [ruby-trunk - Bug #6606][Open] default_external encoding and STDOUT and UTF-8 — "shyouhei (Shyouhei Urabe)" <shyouhei@...>
[#45780] Re: [ruby-changes:24083] nobu:r36134 (trunk): process.c: no method calls in async-signal-safe — Tanaka Akira <akr@...>
2012/6/19 nobu <ko1@atdot.net>:
[#45794] :new_pgroup and :pgroup option for spawn. — Tanaka Akira <akr@...>
process.c で気がついたのですが、spawn に Windows 用の :new_pgroup というオプションが
こんにちは、なかむら(う)です。
2012年6月25日 11:27 U.Nakamura <usa@garbagecollect.jp>:
こんにちは、なかむら(う)です。
2012年6月25日 11:52 U.Nakamura <usa@garbagecollect.jp>:
こんにちは、なかむら(う)です。
2012年6月25日 12:13 U.Nakamura <usa@garbagecollect.jp>:
こんにちは、なかむら(う)です。
[#45818] [ruby-trunk - Feature #6643][Open] io.seek(off, :end) — "akr (Akira Tanaka)" <akr@...>
At Mon, 25 Jun 2012 19:32:06 +0900,
2012年6月25日 23:37 SATOH Fumiyasu <fumiyas@osstech.jp>:
[#45826] Question: Thread#kill doesn't throw Exception — SASADA Koichi <ko1@...>
ささだです.
> さらに突っ込んだ質問:
(2012/06/26 4:25), KOSAKI Motohiro wrote:
[ruby-dev:45820] Re: 非同期割り込みに対する対処案(日本語版)
2012年6月25日 19:39 SASADA Koichi <ko1@atdot.net>: > > (1) 結局,デフォルトの挙動はどうするべきか? まず、SIGINT (^C) で ruby を終了できることはとても重要ですから、 これについては即座に例外になるべきでしょう。 SIGTERM など他のシグナルも同様だと思います。 それ以外については、100% コンパチブルという話を尊重するなら、 やはりそれも現状どおり即座に例外なんじゃないでしょうか。 尊重しないなら、遅延させるという選択肢もあるかもしれません。 > (2) Thread.delay_interrupt を呼ぶ前と,呼んだ後のブロックの中ではどのよ > うに挙動は変化するか? ブロックの内側では非同期イベントに対する例外は safe point まで遅延します。 外側については、さらに外側で Thread.delay_interrupt で括られているかどうかに 依存します。 > (3) Thread.blocking_interruptible() を呼ぶ前と,呼んだ後のブロックの中で > はどのように挙動は変化するか? ブロックの内側については、ブロッキング操作が safe point になります。 外側については、さらに外側で Thread.blocking_interruptible や Thread.blocking_uninterruptible で括られているかどうかに依存します。 > (4) Thread.blocking_uninterruptible() を呼ぶ前と,呼んだ後のブロックの中 > ではどのように挙動は変化するか? ブロックの内側については、ブロッキング操作が safe point でなくなります。 外側については、さらに外側で Thread.blocking_interruptible や Thread.blocking_uninterruptible で括られているかどうかに依存します。 > 私の推測・意見です: > (1) については特に規定していない気がします.間違ってたらすみません. > (2) は,上記の説明とメソッド名からどっちがどっちだかわかりませんでした. > (3) は モード1, 2 -> モード2 への制御を行う? > (4) は モード0, 1 -> モード2 への制御を行う? > (3, 4) があれば, (2) は不要じゃないか? 私が書いた時点ではモード 0, 1, 2 という考え方ではなかったのでしょう。 ブロックする操作やそれ以外の場所を safe point とするかどうかを制御する感じに だったように思います。 > あと,よくよく考えると,Thread.blocking_uninterruptible などで,klass > の指定が n 個ネストすると,非同期割り込みが起こる度に n 回チェックする必 > 要がある気がします.包含関係があるので,単純にそうではないんですが.継承 > 関係を考えると,ハッシュで O(1),というわけにもいかない(飛んできた例外 > オブジェクトの継承木の高さが m 個の場合,O(m) でいけるか). そうですね。 > また,[ruby-talk:294917] ではキューで管理するべき,ということでした > が,種類によって割り込みが追い越す可能性があります(例えば,TimeoutError > がブロックされており,キューに貯まっているとき,InterruptError が来たら > どうなるか). 追い越すのではないかと思います。 > (5) チェックのコストをどう考えるか(O(m) は甘受すべきコストか) 非同期イベントはそのコストが問題になるほど頻繁に使うべきものではないんじゃないでしょうか。 原則的には、プロセスの終了のためにのみ使うべきだと思っています、 > (6) 追い越しが発生するとき,どうすると良いか 追い越せばいいんじゃないでしょうか。 なにを問題と感じているのかわかりません。 > あと,[ruby-talk:294917] では "It is because Thread.check_interrupt > with blocking operations causes race conditions." と,race が起こるとか > いてあるんですが,これどういう話でしたっけ. あぁ、race もありますが、もっとあからさまにブロックしている最中に 中断できなければならないというほうがわかりやすい必要性かもしれません。 race は、ブロックする直前や直後にシグナルが来たときの話を想定していました。 もし Binary Hacks を持っているなら「sigsafeでシグナル処理を安全にする」という のを読んでみてください。 -- [田中 哲][たなか あきら][Tanaka Akira]