[#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:45353] Re: 非同期割り込みに対する対処案(日本語版)

From: Urabe Shyouhei <shyouhei@...>
Date: 2012-03-13 02:56:35 UTC
List: ruby-dev #45353
On 2012年03月12日 21:00, Yusuke Endoh wrote:
> もっと細かいことを言うと、POSIX thread では mutex のロック待ちは
> ブロックしうるけれど cancellation point になっていません。
> その理由は、推測ですが
> 
>   - mutex のロックで割りこまれるようではプログラムを書くのが難しい
>   - cancellation point に関係なく、mutex はロック内の処理を一瞬で
>     終了することが求められていて、ロックで「ブロック」するほど待つ
>     ケースは想定されていない
> 
> などかと思います。

POSIXではキャンセルが起こるとただ処理が中断されるのではなくクリーンアップ
ハンドラが動くことがあります。ここで、条件変数を待っているスレッドがキャン
セルされた時にクリーンアップハンドラに突入すると、そのハンドラ内で条件変数
が待っていたmuetxはロックされた状態で突入してくることになっています。した
がってクリーンアップハンドラは常にmutexをロックしている前提で書いてよいこ
とになっています。ところがmutexのキャンセルがOKということにすると、クリー
ンアップハンドラはmutexがロックされているのか、ロックされていないのかよく
わからないような感じで動くということになります。これは正しく書くのがとても
面倒です。

といったことがpthread_cond_wait(3posix)のRATIONALEに書いてあります。

In This Thread