5.4. スレッドと連絡

既存パーティションのディスクスキャンやパッケージメタデータのダウンロードなど、インストール中に実行するアクションには時間のかかるものもあります。これらを待機すること避け、可能な範囲で応答できるようにするために、Anaconda ではこれらのアクションを個別のスレッドで実行します。

Gtk ツールキットはマルチスレッドからの要素変更をサポートしません。Gtk のメインイベントループは Anaconda プロセス自体のメインスレッドで実行され、GUI に関与するすべてのコード実行アクションもメインスレッドで実行される必要があります。これを行う唯一の対応方法は GLib.idle_add を使うことですが、これは必ずしも容易ではなく、推奨されません。この問題を軽減するために、いくつかのヘルパー関数とデコレーターが pyanaconda.ui.gui.utils モジュールで定義されています。

最も便利なものは @gtk_action_wait および @gtk_action_nowait デコレーターです。これらは、装飾された関数やメソッドを変更し、これらが呼び出されると自動的に Gtk のメインループにキュー登録され、戻り値が発信者に返されるか切断されるようにします。

マルチスレッドを使用する理由の 1 つは、他の画面で設定を実行中の間 (インストール先 でパッケージメタデータをダウンロード中の場合など)、別の画面でユーザーが設定を進めることができるという利点です。実行中のスポークでの設定が終了したら、このスポークはその旨を連絡してブロックされないようにする必要があります。これは、hubQ というメッセージキューによって処理され、メインイベントループで定期的にチェックされています。スポークがアクセス可能になると、その旨とブロックされないべきであるとのメッセージをこのキューに送信します。

スポークがステータスまたは完了フラグをリフレッシュする必要がある場合にも、同様のことが適用されます。設定および進捗状況 ハブには progressQ と呼ばれる別のキューがあり、インストールの進捗状況更新を送信するロールを果たします。

テキストベースのインターフェイスでは状況はより複雑になりますが、ここでもこれらのメカニズムは必要になります。テキストモードではメインループがなく、多くの場合にキーボード入力を待機することになります。