Closed Hiroshiba closed 7 months ago
Rust APIで同期版を作り、非同期が難しそうな言語では同期版を提供する。
Rust API側(voicevox_coreグレート)は変える必要はないと思います。 それぞれの言語バインディングでRUNTIME.block_on(C APIのように)すればシグネチャの変更だけで済むと思います。
Rust API側(voicevox_coreグレート)は変える必要はないと思います。 それぞれの言語バインディングでRUNTIME.block_on(C APIのように)すればシグネチャの変更だけで済むと思います。
その手もあるかなと思います。 最終的にRust APIでも同期版を提供する方針であれば、それを作って各言語でラップする形が良いのかなーと。
そのRUNTIME.block_on
で包むのをRust APIで一括でやってしまえば、APIとしての見通しと統一性が向上するんじゃないかと思っています。
RUNTIME.block_on
をFFI側から減らせればたぶんすっきりするし、混乱も減らせるんじゃないかと思います。
例えば今私が見つけたPython APIのここ、 #555 の後に #553 を入れたときに考慮が漏れてましたが、このtokio::sync::Mutex
およびそれに伴うRUNTIME.block_on
はもう要らないはず。こういうのも減らせるかと。
手元でasync def
の外でpyo3-asyncioの関数を呼んでみたのですが、その際起きることとしてはコルーチンが返されて後でTypeError
になるのではなく、その場でRuntimeError
を吐くようです。
async def
の挙動としては怪しくなっている気もしてきますが、まあ好都合ではあるかもしれません。
>>> synthesizer = asyncio.run(Synthesizer.new(openjtalk))
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
RuntimeError: no running event loop
(追記) まあRuntimeError: no running event loopが発生します
みたいなタイトルのissueが一回くらいここに立つことにはなると思いますが。
onnxruntimeがどうなってるのか、SessionのAPIを見てみました。
onnxruntimeは全言語で全然違うインターフェースを持っていそうな雰囲気を受けました。別々な設計方針で開発してる・・・?(流石にそれはめちゃめちゃ大変そう。。。)
内容
Python版のAPIを眺めていたのですが、普段駆け出しのPythonユーザーがおそらく1回も見たことがないであろうasyncが必須になっていることに気づきました。 asyncはPythonのどの標準ライブラリにもおそらく現れておらず(?)、しばらくプログラミングをしていた方ですら扱い方を知らない人の方がおそらく多いくらい難しいと思います。 なんとなくの直感ですが、VOICEVOX COREを手に取ってくれたプログラマーの3割は脱落しそうかなと・・・。
可能であれば同期版APIを提供してあげるとユーザ数は飛躍的に伸びるだろうなと思いました。 どういう方法があるか、やるやらも含めて議論できるといいのかなと思い、issueを立ててみました。
Pros 良くなる点
初学者に優しくなる
Cons 悪くなる点
下手したら関数の量が倍になる
実現方法
Rust APIで同期版を作り、非同期が難しそうな言語では同期版を提供する。 (非同期が一般的な言語ではasync版だけでもいいかも・・・?)
VOICEVOXのバージョン
0.15より後?
その他
0.15では非同期版だけの提供でいいのかなと思いました! できる限り優しいexampleにしてあげたいですね・・・!