From: Yusuke ENDOH <mame@...>
Date: 2010-05-06T20:40:06+09:00
Subject: [ruby-dev:41188] Re: MonitorMixin::ConditionVariable#wait timeout

遠藤です。

2010年5月6日20:13 Tanaka Akira <akr@fsij.org>:
> 2010年5月6日19:58 Yusuke ENDOH <mame@tsg.ne.jp>:
>
>> Mutex.sleep は pthread_cond_timedwait で実装されているため、API 上で
>> relative time を受け取ってもシステムクロック変更対策は実現できないの
>> ではないでしょうか。
>
> そうですね。
> relative time で受け付ける機能数がある環境でしか完全には実現できない
> かもしれません。
> (MacOS X の pthread_cond_timedwait_relative_np とか?)
>
> そういう環境では正しく動き、そうでない環境では残念ですが
> 時刻を巻き戻した場合は遅くタイムアウトすることになるでしょう。
>
> しかし、absolute time しか指定できなければ、
> 遅くタイムアウトしないという機能を提供することは不可能です。

そうですね。両方受け付けられるようにするのに反対ではありません。


>> えーー。と思いますが、CV#wait に timeout を入れた akr さんは一時的に
>> thread.rb のメンテナであると考えます。[Bug #2629] の件もあわせて引き
>> とって頂けるなら、反対しません。
>
> 私は自分が thread.rb のメンテナであるとは考えていません。

[Bug #2629] は CV#wait に timeout が入ったせいで生じた問題です。

#2629 の機能は、細かいことを言えば仕様変更を伴います。それが小崎さんの
言うように「ないとまずい」機能だとしたら、CV#wait に timeout を追加する
際の API 設計に不備があったということだと思います。
なので、原則に従えば revert しか選択肢はありません。

ただ、それなりに安定していて需要もあるらしい機能なので、thread.rb の
メンテナがいればその裁量の範囲内で決めていいのでは、と思います。
akr さんが (一時的でいいので) メンテナとなって処理してくれませんか。

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