Module fetch_limit 

リソース取得の同時実行を種別横断で制御する。

仕様は spec/resource_loading.md（実装順序の 4「キューを 1 本に統合し、 種別ごとの優先度を持たせる」に相当する最小実装）。

なぜ要るのか

【2026-08-05】フォントと画像でワーカー上限を別々に持っていたため、 実際には最大 8 本が同時に TLS 接続を張っていた。 この自作 TCP/TLS スタックは同時接続に弱いことが既知で （spec/TODO.md の「接続回数依存の劣化」）、 CSS/JS も非同期化したところメイン HTML が読み込めなくなった （[NET][STATS] total=3、正常時は 13）。

上限は種別ごとではなく全体で持たないと意味がない。 さらに、メイン HTML はページの他の何よりも優先される （それが無ければ描くものが無い）。

方針

• 同時に走るリソース取得ワーカーの総数に上限を設ける
• メイン HTML の取得中はリソース取得を新たに始めない

グローバル状態を持つが、判定そのものは純粋関数へ切り出してあり 単体試験で固定してある（tests/src/test_fetch_limit.rs）。

Enums

Kind

リソースの種別。値が小さいほど優先。

Constants

KIND_FONT

種別: フォントワーカー。

KIND_IMAGE

種別: 画像ワーカー。

MAX_TOTAL_FETCH_WORKERS

同時に走らせるリソース取得ワーカーの総数上限。

Statics

ACTIVE 🔒

現在走っているリソース取得ワーカーの総数。

DRAW_STAGE

ブラウザの draw() がどの段にいるか。

FONT_WORKERS_DIED

死んだフォントワーカーの数（font_queue::pump が回収する）。

IMAGE_WORKERS_DIED

死んだ画像ワーカーの数（image::pump が回収する）。

MAIN_LOAD_IN_FLIGHT 🔒

メイン HTML を取得中か。

OWNER_KIND 🔒

所有者の記録。pid の下位ビットに種別を混ぜず、別配列で持つ。

OWNER_PID 🔒

枠の所有者 PID。0 は空き。

SCRIPTS_PENDING 🔒

保留中・実行中の