change: Rust APIの脱Tokioと、voicevox_core::{tokio→nonblocking}

[qryxip]

内容

題名の通りです。

#830 (comment)についてはTODOとして残し、脱TokioとパブリックAPIのリネームに絞っています。

関連 Issue

ref #388

その他

[Hiroshiba]

なぜtokioを脱したいのかのwhyをこのプルリクエストに関連付けておくと、後から見返すときとか後から入ってきた方に優しいかもと思いました！
（tokioがマイナーなら問題ないけど、確か結構デファクトなんでしたっけ）

tokioではなくnonblockingだとランタイムが不要で、wasmなどの特殊な環境でもブロッキングできるようになるから、とかでしたっけ。

どこかで理由のコメントがあったと思いますが、そこの URL とかで良さそう！

[Hiroshiba]

･･･････あれ、これどういうことでしたっけ。。。

blokingモジュール（クレート）があって、これはAsyncを実装してくれてる感じ･･･？
（プレーンなRustのasyncは非同期の機能がなく、非同期用のクレートを使わないと非同期にできない、という理解でいます）

blocking、名前めちゃくちゃややこしいですね･･･。

[qryxip]

そうですね。こんな感じです。

• blocking: 外部ライブラリ名。VOICEVOX COREのパブリックAPIとしてはドキュメントのみ登場
• voicevox_core::blocking: パブリックAPIの一部
• voicevox_core::nonblocking: パブリックAPIの一部。内部でblocking（外部ライブラリ名）を使っている

blocking、名前めちゃくちゃややこしいですね･･･。

ですね。

前身としてunblockという、unblock::unblock(…)という形で使えるクレートがあって更新が途絶えているのですが、よく見たらこれblockingより前に誕生したものですね。なんでこの名前にしなかったんだろう…

2回くらい言ったかもしれませんが、せめてリポジトリ名（smol-rs/blocking）がblocking-rsとかだったらそっちで呼べるのに…

[Hiroshiba]

LGTM！！！

コード的には問題なしなので、任意のタイミングでマージしていただければ！！
一部質問コメントだけしました！

[qryxip]

なぜtokioを脱したいのかのwhyをこのプルリクエストに関連付けておくと、後から見返すときとか後から入ってきた方に優しいかもと思いました！ （tokioがマイナーなら問題ないけど、確か結構デファクトなんでしたっけ）

コードのドキュメントとしては脱Tokioのメリットを書きましたが、GitHubではどこにも書いてませんでしたね。ちょうど今 VOICEVOX/voicevox_project#56 で話している「PRの結論」を、why込みで書いてみました。

Tokioに依存したプログラムは、async-stdやsmolで使うことはできない。一方、
現在のVOICEVOX CORE Rust APIのTokio依存部分は
`tokio::task::spawn_blocking`のみである。そのため
`tokio::task::spawn_blocking`を、同等の機能を持つblockingクレートのも
のに置き換えることでRust APIの"脱Tokio"を行う。

https://docs.rs/crate/blocking

またこの"脱Tokio"に伴い、Rust APIの`voicevox_core::tokio`を
`voicevox_core::nonblocking`にリネームする。

Python APIではpyo3-asyncioが現在Tokio版かasync-std版しかない状態なので、
Tokioに依存した状態のままにしてある。またtest_utilやdownloaderではこれま
で通りreqwestに依存する。

また将来`Synthesizer`や`OpenJtalk`なども`trait Async`をベースにした設計
にすることを考えているが、本PRではTODOコメントを残すのみにしてある。

https://github.com/VOICEVOX/voicevox_core/pull/830#discussion_r1750081919

tokioではなくnonblockingだとランタイムが不要で、wasmなどの特殊な環境でもブロッキングできるようになるから、とかでしたっけ。

WASMのためではないですね。WASMだとスレッドプールすら使えないので、 #830 ではSingleTaskedという名前を絞り出してまで別実装を用意した、という感じでした。