mutabilityとasyncnessを仕上げる

[qryxip]

内容

現在、SynthesizerにVVMのload/unloadをするためにはそのSynthesizerを「専有」する必要があります。その「専有」がmutexで成されるにせよ規約で成されるにせよ、非同期(async)で実行可能というコンセプトを損います。先日#513の一応の結論が出ましたが、Python APIにおいてはIO-bound/CPU(GPU)-boundな処理をasyncioの文脈に統合するという役割が残っています。

そこで次のことをして、問題を解決します。

• Statusの構造を根本的に変え、次のことを成す

  • 共有参照(&Status)からすべての実行をできるようにする
    • VVMの追加/削除とONNXモデル実行が衝突しないようにする
  • CPU/GPU boundな処理はtokio::task::spawn_blockingで包む
    • モデルの実行に必要なSessionや[impl AnyArray]を、参照を断ち切った'staticな文脈で実行できるようにする

• VVMの追加/削除と、音声合成

Pros 良くなる点

• 上記の問題が解決される

Cons 悪くなる点

実現方法

#513 (comment)で紹介した以下の実装から、「decodeの並列実行」を抜きます。

qryxip@5d17802

ただしこれは #551 と盛大に衝突しそうな気がします。例えば上記の実装では、id_relationsを丸ごと消し飛ばしています。ただその場合でもさっさとPRとして出さなかった私が悪いというのもあるので、 #551 ベースでまた考え直そうと思います。

VOICEVOXのバージョン

N/A

OSの種類/ディストリ/バージョン

• Windows
• macOS
• Linux

その他

[qryxip]

今 #551 を見ていますが、実装としてはともかく設計思想としては特に衝突しなさそうですね。 #551 ベースで普通に何とかなりそうです。

[Hiroshiba]

issueありがとうございます！！
inference coreとstatusの整理はしないとなーと思ってたので、提案嬉しいです！！

実装早めにみて欲しいということでしたら見に行ってみます🙏
とりあえずdraft PRとか投げてもらえると議論しやすいかも？

#551 の実装は僕ですが、実装はともかく目的は衝突しないだろうなと感じました！

[qryxip]

qryxip@5d17802をそのままdraft PR(#553)にしてみました。

[Hiroshiba]

ありがとうございます！！！