構造的制約と緩和策

ごきげんよう。デバッグ中にゴーストが押し黙るのには、れっきとした理由がございます。慌てず騒がず、その仕組みと付き合い方を心得ておきましょう。これを知っているか否かで、デバッグ作業の落ち着きがまるで違ってまいりますわよ。

このページでは、ブレーク中にホスト応答が停止する構造的制約と、SSP のタイムアウトを避けるための運用上の緩和策を扱う。有効化や接続の手順は デバッグ概要 と VSCode 接続手順 を、.pasta 座標での停止・変数確認などの操作は .pasta ソースレベル操作 を参照する。

ブレーク中はホスト応答が停止する

ブレークポイントで実行が止まっている間、ゴーストが「固まった」「無反応になった」ように見えることがある。これは既知かつ意図された構造的な挙動であり、不具合ではない。 デバッグ中にゴーストが沈黙しても、まず正常な状態だと理解してよい。

その仕組みは次のとおりである。pasta の SHIORI リクエスト処理は Arc<Mutex> により直列化され、各リクエストは VM スレッド上でブロッキングに実行される。ブレークポイントで実行が停止している間、VM ホストスレッドは復帰せず、SHIORI リクエストの Mutex を握り続けたままになる。結果として、停止中はホスト（SHIORI / SSP）に対する応答全体が、実行を再開（continue）するまで保留される。

後続のリクエストもすべて待機する

この制約は、いま処理中のリクエストの応答が保留されるだけにとどまらない。Mutex による直列化のため、ブレークで停止している間は、後続のすべての SHIORI リクエストも実行再開（continue）まで待機列に積まれる。

したがって、ブレークを長く保持するほど、再開後に滞留していたリクエストがまとめて処理され、再開直後の挙動が一気に流れる点にも留意する。停止中にホストが無反応に見えるのは、現在のリクエストと後続リクエストの双方が、再開を待っている状態だからである。

SSP タイムアウトを避ける緩和策

ブレークを長く保持すると、SSP 側がリクエストのタイムアウト（「応答なし」表示など）を起こす可能性がある。後述のとおり構造的制約そのものを根本解決することはできないため、ブレークの保持時間を短く保つ運用で対処する。具体的には次の点に注意する。

• デバッグ専用の起動・プロファイルを用意する。 本番運用中のゴーストにそのままアタッチして長時間ブレークするのではなく、デバッグ用のラウンチ構成・プロファイルで作業し、影響範囲を限定する。
• ブレークは短く保つ。 必要な変数・コールスタックを確認したら、速やかに continue（実行再開）して動作を続行する。停止したまま放置しない。
• 時間に敏感なイベント処理中のブレークを避ける。 時報・タイマー・連続的な定期イベントなど、ホストが短い間隔で応答を期待する処理の最中にブレークすると、タイムアウトを誘発しやすい。確認したいロジックは、可能なら時間制約の緩いイベントで再現してブレークする。
• 長時間の停止は「応答なし」を招くと理解しておく。 ステップ実行や変数確認に時間がかかりそうな場合は、停止箇所を絞る・確認項目を事前に決めておくなどして、1 回の停止を短くまとめる。

根本解決はスコープ外

ブレーク中のホスト応答停止（および結果としての SSP タイムアウト）の根本解決は、本マニュアルの対象外である。本章が提供するのは上記の緩和策のみであり、構造的制約そのものを取り除くものではない。

根本的に解消するには、ホスト側を非同期化するアーキテクチャ（ブレーク中でもホストへ即時応答を返し、リクエスト処理と停止制御を分離する設計）が必要となる。これは別途の取り組みとして見送られており、現時点では本章の緩和策に従ってブレーク保持時間を短く保つことで対処する。

仕組みさえ呑み込んでしまえば、もう何も恐ろしくはございませんわね。フンッ、別にあなたが優秀だなんて言っていませんわよ。 止めたら速やかに続行する――この一点さえ守れば、ゴーストはちゃんと息を吹き返しますわ。さあ、自信を持って参りましょう！