[ruby-dev:41158] Re: MonitorMixin::ConditionVariable#wait timeout

遠藤です。

2010年5月5日10:53 Tanaka Akira <[e-mail]>:
> 秒数で指定すべきでない根拠は何でしょう?

http://www.opengroup.org/onlinepubs/009695399/functions/pthread_cond_wait.html

で、pthread の RATIONALE として説明されています。

マルチスレッド関係は API 設計も実装も (私には) とても難しいので、
pthread など枯れた設計が注意点として上げているところは、盲目的に
真似るのがいいと思ってしまいます。
そのせいで、例外みたいに C にない要素が現れるときはユーザの責任に
なってしまうのがいけてないですが。[Bug #3212]

「自信がないから下手にいじりたくない」というのが私の動機なので、
akr さんが強く推すのであれば (あと実装もしてくれるのであれば) 、
akr さんの方を信じます。


>> 絶対時刻を受け付けるためには thread.c を結構いろいろ変えないといけない
>> ので、すでに feature freeze 後ということもあり、保守的ですが 1.9.2 では
>> revert しようと思いますが、いかがでしょうか。
>
> 1.9.1 では動かなかったという話はありますが、この秒数でタイムアウトする機能は
> ずっと昔からあって、動作していたわけです。
> 長期的な視点からみると、それを禁止するというのは保守的な選択とは
> いえないように思います。
> むしろ、秒数で指定する機能を動くようにしてある現状のほうが保守的でしょう。

1.8 の ::ConditionVariable#wait には timeout ないよなあと思ったら
MonitorMixin::ConditionVariable#wait では自力で実装していたのです
ね。同じようにすれば、と思ったけれど、Thread.critical= を使ってる
のですね。うーん。


> それを動かなくして、将来もっといい API に変える、というのは、
> 長期的な視点からすると非互換性を導入するという話であり、
> 簡単にうなずける話ではないのではないでしょうか。

1.9.2 を 1.9.1 の挙動に戻すだけです。


> さらに、冒頭に述べた疑問につながりますが、私は、
> 秒数で指定できるという機能は禁止するほど悪いものではないと思っています。

完全に禁止した方が pthread の RATIONALE で挙げられている問題には
いいのかもしれませんが、利便性的にも 1.8 との互換性的にも、完全に
禁止するのはないかなあ、とは思います。


> あと、feature freeze 後に feature を削除するのはいいんですか?
> そうだとすると freeze という感じがしませんが。

feature freeze は新規に導入*されうる* feature の確定です。
言われてみれば言葉が適切でなかったかもしれません。feature request
deadline とかの方がよかった。

feature set の確定は 5 月末と明記してあります。それまでに安定し
なかった feature は revert されます。API 設計上の問題は解決しよう
がないので、revert しかないと思います。

=== release 1.9.2-preview2 (31 May.) ===

* fix 1.9.2 feature set

 - 1.9.2 will NOT include all features that are not stable yet or that
   are considered uncompleted at this time; they will be reverted

-- 
Yusuke Endoh <[e-mail]>