[#45341] 非同期割り込みに対する対処案(日本語版) — SASADA Koichi <ko1@...>

 ささだです.

28 messages 2012/03/11
[#45816] Re: 非同期割り込みに対する対処案(日本語版) — SASADA Koichi <ko1@...> 2012/06/25

 ささだです.

[#45817] Re: 非同期割り込みに対する対処案(日本語版) — Tanaka Akira <akr@...> 2012/06/25

2012年6月25日 18:26 SASADA Koichi <ko1@atdot.net>:

[#45819] Re: 非同期割り込みに対する対処案(日本語版) — SASADA Koichi <ko1@...> 2012/06/25

 ささだです.

[#45820] Re: 非同期割り込みに対する対処案(日本語版) — Tanaka Akira <akr@...> 2012/06/25

2012年6月25日 19:39 SASADA Koichi <ko1@atdot.net>:

[#45827] Re: 非同期割り込みに対する対処案(日本語版) — SASADA Koichi <ko1@...> 2012/06/25

(2012/06/25 20:32), Tanaka Akira wrote:

[#45841] Re: 非同期割り込みに対する対処案(日本語版) — Tanaka Akira <akr@...> 2012/06/25

2012年6月26日 3:40 SASADA Koichi <ko1@atdot.net>:

[#45372] Marshal.dumpにおけるインスタンス変数の取り扱いについて — keiju@... (Keiju ISHITSUKA)

けいじゅ@いしつかです.

14 messages 2012/03/16
[#45376] Re: Marshal.dumpにおけるインスタンス変数の取り扱いについて — Yukihiro Matsumoto <matz@...> 2012/03/17

まつもと ゆきひろです

[#45377] Re: Marshal.dumpにおけるインスタンス変数の取り扱いについて — keiju@... (石塚圭樹) 2012/03/17

けいじゅ@いしつかです.

[#45381] Re: Marshal.dumpにおけるインスタンス変数の取り扱いについて — Yukihiro Matsumoto <matz@...> 2012/03/17

まつもと ゆきひろです

[#45399] Re: Marshal.dumpにおけるインスタンス変数の取り扱いについて — keiju@... (石塚圭樹) 2012/03/18

けいじゅ@いしつかです.

[#45412] [ruby-trunk - Feature #6177][Open] array.cのrb_ary_equal()の高速化 — "Glass_saga (Masaki Matsushita)" <glass.saga@...>

13 messages 2012/03/20

[#45471] [ruby-trunk - Bug #6230][Open] [WEBrick] WEBrick::HTTPResponse#body の IO オブジェクトの読み込みに read メソッドを使っているため必要以上にブロックされる — "nobuoka (yu nobuoka)" <nobuoka@...>

7 messages 2012/03/30

[ruby-dev:45347] Re: 非同期割り込みに対する対処案(日本語版)

From: Yusuke Endoh <mame@...>
Date: 2012-03-12 12:00:30 UTC
List: ruby-dev #45347
遠藤です。

2012-03-11 SASADA Koichi <ko1@atdot.net>:
> 提案:
>  非同期割り込みをチェックするタイミングを制御するための仕組みを新設す
> る.原案は [1] にあるとおり.ただ,名前については今後検討する.
>
>  制御の種類は次の通り,
>   0. なるべく頻繁にチェックする(これまで通りの動作)
>   1. ブロック I/O のタイミングだけチェックする


一応補足しますと、ブロック I/O に限らずブロックを発生させうる API
は全部チェックすべきだと思います。例えば:

  - 明示的なウェイト (Kernel#sleep)
  - 条件変数待ち (ConditionVariable#wait)
  - スレッド終了待ち (Thread#join)
  - プロセス終了待ち (Kernel#system, Process#wait など)

要するに rb_thread_blocking_region を呼ぶあたり全部。少なくとも
POSIX thread の cancellation point はそう定義されています。


もっと細かいことを言うと、POSIX thread では mutex のロック待ちは
ブロックしうるけれど cancellation point になっていません。
その理由は、推測ですが

  - mutex のロックで割りこまれるようではプログラムを書くのが難しい
  - cancellation point に関係なく、mutex はロック内の処理を一瞬で
    終了することが求められていて、ロックで「ブロック」するほど待つ
    ケースは想定されていない

などかと思います。
ただし Haskell の非同期例外 [2] では mutex のロックも cancellation
point (相当) になっており、デファクトの設計ポリシーがあるわけでは
なさそうです。



> 参考文献:
> [1] Akira Tanaka "Re: Thread#raise, Thread#kill, and timeout.rb are
> unsafe" ruty-talk (2008.3)
> http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/294917

[2] Simon Marlow, Simon Peyton Jones, Andy Moran and John Reppy.
Asynchronous Exceptions in Haskell, in PLDI'01.

-- 
Yusuke Endoh <mame@tsg.ne.jp>

In This Thread