ruby-dev

前田です。
# 一番下にまつもとさんへの質問があります。

Akinori MUSHA wrote:
>> (1) rb_thread_wakeup()のrb_rescue2()
>>
>> rb_thread_wakeup()をrb_rescue2()で実行してThreadErrorを無視する
>> ようにしていますが、THREAD_KILLEDなスレッドはスキップして次の
>> スレッドをwakeupしないと、だれもMutexを獲得できなくなってまずい
>> ような気がします。
> 
> 　別メールの通り、返り値を見てループを継続しているので大丈夫そう
> ですね。

はい、失礼しました。

>> (2) Marshalの対応
>>
>> Marshalでlockでブロックしている時にもdump/loadできるようになって
>> いますが、今のMutexではlock中はdump/loadできないので非互換ですね。
>> JavaのObjectもdump/loadできる(Javaだとモニタ機構はObjectに備わって
>> います)ので問題ないとは思うのですが、この点については十分検討されて
>> いますでしょうか。
> 
> 　気づきませんでした。検討します。

たぶん、問題ないとは思うのですが。
どちらかというと状態によってdumpできたりできなかったりするlib/thread.rb
の方がまずいかもしれないですね。
また、そういう挙動に依存しているアプリケーションはたぶんないんじゃない
かと思います。

>> (6) 実績
>>
>> Mongrelで使っているので実績があるということですが、ConditionVariable
>> は使われていないように思います。
>> どちらかというとConditionVariableの方が問題が起きやすいかもしれません。
>> あと、スレッドがらみだとあるアプリケーションで問題ないからといって、
>> 他のアプリケーションで問題ないとはいえないので、複数のアプリケーション
>> で検証した方が望ましいですね。
> 
> 　これは大きな課題です。マルチスレッドの手頃なテストスイートが
> ないこともありますが、デバッグのしにくさも問題です。

コードを見るかぎりはlib/thread.rbと同じような挙動になっていそうですし、
Producer-Consumerの簡単なサンプルはもちろんうまく動きました。

>> (7) メンテナ
>>
>> fastthreadのメンテナは誰になるのでしょうか?
> 
> 　落ち着くまでは作者の MentTaLguY です。メールでやりとりして
> いる限りコミュニケーションに問題はないので、何かあれば気軽に
> 連絡してあげてください。

了解です。
commit権は今のところ必要ないでしょうか?

> 　テスト促進のため ruby_1_8_6 にも入れて preview してもらって
> いますが、もし問題が見つかった場合には、最終リリースは
> --disable-fastthread をデフォルトにして出荷することにしています。

今のところそうすべき理由はないように思います。

> 　1.8.6 最終リリースをどうするかは、以上のレビュー結果への対応の
> 中で決めたいと思います。

お手数ですがよろしくお願いします。

あと、Mutex#unlockでロック中ではなかったときにselfの代わりにnilを返す
ところまでオリジナルと同じにしてあるところにちょっと感動したのですが、
これってそもそも意図的だったんでしょうか? > まつもとさん

  def unlock
    return unless @locked
    ...
    self
  end

svn annするとrev2のInitial revisionからのようなのですが...。

-- 
前田 修吾