-
Notifications
You must be signed in to change notification settings - Fork 118
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
change: VoiceModel
→ VoiceModelFile
#832
change: VoiceModel
→ VoiceModelFile
#832
Conversation
0432206
to
f32872e
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
なるほどな設計に思いました!!
すみません、インターフェイスを見て今更思いついたのですが、これってc api等で2つ以上のSynthesizerにopen済みのModelFileを登録(ロード?)した場合に問題などは生じそうでしょうか?
(どうするかはさておき、一旦問題が起きそうかだけお聞きしてる感じです!)
現行実装と変わらず、特に問題無く並行実行できるはずです。close時に1箇所以上からのアクセスがまだ走ってるなら、そのすべてが終わるまでロックするという感じです。私がreader writer lockと言ったやつについては(呼び方は違いますが)以下リンクで解説されています。 (まあ並行実行のテストは無いです。が、並行実行のテストというのも難しいのでこういう感じのベンチのコードを管理して手軽に確認できるようにするという感じがよさそう) |
おおなるほどです!!問題なさそう! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
良さそう!!!
いくつか細かいコメントをさせていただきました!
ほぼLGTMなのですが、Python版に関してちょっと気になることがあったのでそこだけという感じです!
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
このコードをそのままChatGPT 4oに投げ付けてみたら一発で満点の答えを返してくれた。こういうところではコメントでの説明を省いていきたいなーと個人的には思っている。
https://chatgpt.com/share/66ea8dce-a580-800c-b4fd-37af1084bfa5
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
実装の中身については、G: 'a, T: 'static
(∀.'a
)という制約を入れることで"T
ourlives G
"の関係にしてouroborosに突っ込めばSafe Rustで記述しきれる、というのが肝。
ただChatGPTがこのことに辿り着くのは難しそう。「この'a
は?」って聞いてもわかってなさげな答えを返してきた。
…やっぱコメント書くべきか?いやRust詳しい人ならわかるだろうし…
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
T: 'static
についてwhyのコメントが要りそうだったので、今回の場合はdocstringに入れることにしました。
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
あ!!! T
outlives G
の関係にするのにT: 'static
にする必要は無い!
ということで、whyのドキュメントは消えてまたコメント無しに…
74a482d
(#832)
追記: さらに改修して、今はこんな感じになりました。
https://github.com/qryxip/voicevox_core/blob/aed651b9105046b37036f0178368abdf15b96f64/crates/voicevox_core/src/__internal/interop/raii.rs#L10-L43
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ここについて色々考えてみて結論としては
- Rust初学者には相当難しい
- とはいえここはユーティリティで、ここを変更しに来る人はものすごい珍しい
- なので、求めてるものはここじゃないことがわかればいい
try_map_guard
という名前はwhatもわからないけど、処理を大きく変えてくるような印象はない- つまりスルーしても良さそうには感じる
- 総合すると、今の形で OK !
という感じかなと!!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!!!
勉強になりました、ありがとうございます!!
まだちょこちょこコメント書いているんですが、そのままマージで問題ないと感じています!
気が向いたらくらいの気持ち!
`VoicevoxVoiceModelFile`の次のゲッター関数を、ゲッター関数ではなくする。 - `voicevox_voice_model_file_id` `uint8_t (*output_voice_model_id)[16]`に吐き出すようにする。 - `voicevox_voice_model_file_get_metas_json` `voicevox_voice_model_file_create_metas_json`に改名。 ねらいとしては VOICEVOX#832 のような設計をC APIでも行うことで、サードパーティの バインディング製作者の労力を減らすため。上記のゲッター関数がゲッターでは なくなれば、オブジェクトへのアクセスを完全に管理できる。 VOICEVOX#849 (comment)
`VoicevoxVoiceModelFile`の次のゲッター関数を、ゲッター関数ではなくする。 - `voicevox_voice_model_file_id` `uint8_t (*output_voice_model_id)[16]`に吐き出すようにする。 - `voicevox_voice_model_file_get_metas_json` `voicevox_voice_model_file_create_metas_json`に改名。 ねらいとしては #832 のような設計をC APIでも行うことで、サードパーティの バインディング製作者の労力を減らすため。上記のゲッター関数がゲッターでは なくなれば、オブジェクトへのアクセスを完全に管理できる。 #849 (comment)
内容
#829 を行います。変更は大体こんな感じです。
VoiceModel
(C以外)VoiceModelFile
(C以外)VoicevoxVoiceModel
(C)VoicevoxVoiceModelFile
(C)VoiceModel
をコンストラクトする。VoiceModel::from_path
(Rust, Python)VoiceModelFile::open
(Rust, Python)voicevox_voice_model_new_from_path
(C)voicevox_voice_model_file_open
(C)VoiceModelFile::close
(Rust, Python, Java)VoiceModelFile.__a{enter,exit}__
(Python, Java)voicevox_voice_model_delete
(C)voicevox_voice_model_file_close
(C)Synthesizer::load_voice_model
中にVoiceModelFile::close
したときの挙動はこんな感じになっているはずです。ただしまだこれらについてのテストは書いてませんし手動での確認もやってません。Synthesizer::load_voice_model
中にclose
したときの挙動例外(Javaと同様にロックして待つException
)を発するload_voice_model
が終わるまでロックして待つ[追記1] Python APIで
load_voice_model
が終わるまでロックして待つのが面倒そうに感じたのでこうなってしまったのですが、よく考えたらそんなに難しくなかった。それよりもロックするようなデザインにするか例外を発するようなデザインにするかですね。[追記2] ロックする方のデザインの方がいいかもですね。reader-writer lockが一つあれば実装できますし、C APIにもAPIをシンプルにしたまま仕込める。
[追記3] Python APIをロックするデザインにしてしまいました。こんな感じになります。
関連 Issue
Resolves #829.
その他