[#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:45835] Re: 非同期割り込みに対する対処案(日本語版)
> の3つになるような気がしていますので,ある例外がこれら 3 つのどの状態に > するか,という API を考えてみました. > > (a) Thread.interrupt_mask(exception, state) do; end > (b) Thread.interrupt_mask(hash) do; end (b)のほうは指定した全ての変更がアトミックに切り替わらないと絶対文句が出るAPIだと思うのですが、はたしてそんなことが可能でしょうか また、blocking_interruptibleのときが、pthread cancel モデルなのであれば、 自発的に例外を確認する pthread cancel() 関数相当のメソッドが必要だと思います > :immediate_interruptible > :blocking_interruptible > :uninterruptible メソッド名と引数の両方に interruptの単語が入っているのはやや冗長ではないでしょうか > (1) シグナルを許すと言っても,SIGUSR1 とかも許していいのかな. シグナル毎に違うExceptionを投げるべきだと思います。全部SignalExceptionの サブクラスにすれば既存のコードで動くんじゃないでしょうか >(2) POSIX みたいに,このメソッドは blocking とか,すべてきちんと > 書き連ねる必要があるのかな.かなり,無理な気がする > (そもそも,何がどのメソッドを呼び出すかわからない気が). 当面GVL離すところで、チェックするようにして、GVL離すタイミングを 徐々に増やしていくとかですかね。 >(3) ライブラリの至る所でこんなの書かれたらハッシュが大量発生して, > オーバヘッドで大変になったりしないだろうか.... > そもそも,これって多用するんだろうか. わたしの想定は、1行目で blocking_interruptible にして二度と変えない。 ensureの中でIOを呼ぶときだけ一時的に uninterruptibleに変更 > (4) ブロックを持たない Thread.mask_interrupt() は許すべきだろうか. > (意味としては,「この呼び出し以降はこの設定で」,という感じ) > なんとなく,許さない方がいいような気がするんだけど (3)とあわせてブロック必須だと全プログラムが一段ネストが深くなるので うれしくないなあ > (5) Thread.mask_interrupt() はネストしたら設定を混ぜていく,としたけど > 単に,置き換える,という選択肢もあるのか.こっちのほうが使いやすい? 混ぜていく。というのがなにを指しているのか取れなかったので置き換えるモデルで動作例を書いていただけるとうれしいです