-
Notifications
You must be signed in to change notification settings - Fork 201
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
整理: CancellableEngine
を明確化
#1448
base: master
Are you sure you want to change the base?
Conversation
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.
仕組み難しいですね!!!
「音声合成用のプロセスをいっぱい持っておいて、リクエストが来たら合成を開始し、合成が終わるかリクエストがキャンセルされたらプロセスを待機状態に戻す」というだけなのですが、パーツごとに分かれてると途端に解読が難しくなりますね。。
わかりやすくなっていると思うのですが、いくつか惜しいなと感じたので主にコメントに関してコメントしました!
たぶん、_watching_reqs_and_procs
と_waiting_procs_and_cons
のより良い名前が思いつけば勝ち。
パラメータ use_gpu, voicelib_dirs, voicevox_dir, | ||
runtime_dirs, cpu_num_threads, enable_mock は、 core_initializer を参照 | ||
init_processesの数だけプロセスを起動し、procs_and_consに格納する |
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.
(細かいけど)
「その他の引数はcore_initializerを参照」とかにすると、引数名とドキュメントの密結合を防げるかもです。
# Requestは接続の監視に使用され、Processは通信切断時のプロセスキルに使用される | ||
# クライアントから接続があるとlistにtupleが追加される | ||
# 接続が切断、もしくは音声合成が終了すると削除される |
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.
ここ、平易な説明でわかりやすいなと感じました!!!
「接続の監視」を「切断の監視」とするとよりわかりやすいかも。
# Requestは接続の監視に使用され、Processは通信切断時のプロセスキルに使用される | |
# クライアントから接続があるとlistにtupleが追加される | |
# 接続が切断、もしくは音声合成が終了すると削除される | |
# Requestは切断の監視に使用され、Processは切断時のプロセスキルに使用される | |
# クライアントから接続があるとlistにtupleが追加される | |
# 切断、もしくは音声合成が終了すると削除される |
sub_proc_con1, sub_proc_con2 = Pipe(True) | ||
ret_proc = Process( | ||
def _start_new_process(self) -> tuple[Process, ConnectionType]: | ||
"""音声合成可能な新しいプロセスを開始し、そのプロセスとそこへのコネクションを返す。""" |
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.
不明瞭な代名詞は展開してあげるとより確実
"""音声合成可能な新しいプロセスを開始し、そのプロセスとそこへのコネクションを返す。""" | |
"""音声合成可能な新しいプロセスを開始し、そのプロセスと、プロセスへのコネクションを返す。""" |
watch_con_listからの削除、プロセスの後処理を行う | ||
プロセスが生きている場合はそのままprocs_and_consに加える | ||
死んでいる場合は新しく生成したものをprocs_and_consに加える | ||
合成の後処理をおこなう。 |
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.
音声合成の後処理と勘違いされるかも
# 監視対象リストから除外する | ||
try: | ||
self.watch_con_list.remove((req, proc)) | ||
self._watching_reqs_and_procs.remove((req, proc)) | ||
except ValueError: | ||
pass | ||
|
||
# 待機中リストへ再登録する | ||
try: |
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.
この辺りちょっとややこしいかもですね!
監視も待機の1つなのと、登録ってなんだっけ?となりました。
案ですが、_watching_reqs_and_procs
と_waiting_procs_and_cons
をそれぞれ_request_pool
と_process_pool
にしちゃうのとかどうでしょう・・・・?
そうするとここのコメントは、1つ目の方はコメントがいらないほど明確で、2つ目は「プロセスを待機中に戻す」とかにできるなーと。
ただそうすると、(Request, Process)
のtupleを_request_pool
に入れることになってなんか変な感じはあるのですが。。。
そこはこう。。コメントでうまいこと説明する感じ・・・は難しいですかね。。。。。
音声合成を行う関数 | ||
通常エンジンの引数に比べ、requestが必要になっている | ||
また、返り値がファイル名になっている | ||
サブプロセス上において、音声合成用のクエリ・スタイルIDに基づいて音声波形を生成し、音声ファイル名を返す。 |
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.
平易に。
サブプロセス上において、音声合成用のクエリ・スタイルIDに基づいて音声波形を生成し、音声ファイル名を返す。 | |
サブプロセスで音声合成用のクエリ・スタイルIDから音声を生成し、音声ファイル名を返す。 |
assert len(tts_engines.versions()) != 0, "音声合成エンジンがありません。" | ||
|
||
# 「キュー入力待機 → キュー入力受付 → 音声合成 → ファイル名送信」をループする |
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.
入力待機と入力受付の違いがわからず混乱するかも
内容
概要:
CancellableEngine
を明確化CancellableEngine
はリファクタリングが進んでいない。現時点で「プライベート・パブリック命名規則」「変数名の略称」「docstring とコードコメントの使い分け」などに課題がある。このような背景から、
CancellableEngine
を全体的に明確化するリファクタリングを提案します。PR 単位を大きくする方針に従い、本 PR では
CancellableEngine
内部に必要なリファクタリングを全て実装しています。関連 Issue
無し