---
generated_at: 2026-02-22 12:00:00
metrics:
  claims_total: 78
  claims_with_evidence: 74
  claims_without_evidence: 4
confidence_derived: 0.95
---

# 根拠レポート：src-thread 単体テストケース一覧

## 本レポートについて

### 目的
本レポートは、生成された設計書・ドキュメントの信頼性を検証し、人間レビュアーが効率的にレビューできるようにすることを目的としています。

### チェック方法
以下の観点でドキュメントの内容（Claim：主張）を検証しています：

1. **根拠の有無確認**：各主張に対して、ソースコード・既存設計書・要件定義書などの根拠（Evidence）が存在するか
2. **根拠との整合性**：主張の内容が根拠と矛盾していないか
3. **網羅性**：参照すべき情報源を適切にカバーしているか

### 信頼度スコアの算出
- **confidence_derived** = 根拠あり件数 / 総主張件数
- 状態「○」：根拠あり、「△」：根拠不足または要確認

### 本レポートの使い方
1. まず「サマリー」で全体の信頼度と優先レビュー項目を確認
2. 「Claims と根拠の対応」で △ の項目を重点的にレビュー
3. 「不足情報」で補完が必要な情報源を確認

---

## 1) サマリー（まず見るところ）
- 総合信頼度（derived）：**0.95**
  - 根拠あり：74 / 78、根拠なし：4
- 優先レビュー（高）
  1. **UT-THR-005（count=UINT_MAXの境界テスト）**：実際の挙動はプラットフォーム依存で根拠不足
  2. **UT-THR-016（b->in != 0でabort）**：assert文とabort()の組み合わせ挙動について確認要
  3. **UT-THR-029（スタックサイズ8MB）**：ハードコードされた値の妥当性は外部仕様なし
  4. **UT-THR-076（pthread_atfork登録）**：Unix固有の動作でWindows環境ではテスト不可

## 2) 参照した情報（Evidence一覧）
> ここに「実在するもの」だけ列挙。抽出フェーズで付けたIDをそのまま出す。

- E-01: `src/thread-common.c` - バリア関連関数（uv_barrier_init/wait/destroy）の実装
- E-02: `src/threadpool.c` - スレッドプール関連関数の実装
- E-03: `include/uv.h` - パブリックAPI宣言（uv_barrier_init, uv_barrier_wait, uv_barrier_destroy, uv_queue_work, uv_cancel等）
- E-04: `include/uv/threadpool.h` - 内部構造体uv__workの定義
- E-05: `src/threadpool.c:30` - `#define MAX_THREADPOOL_SIZE 1024` マクロ定義
- E-06: `src/threadpool.c:39` - `static uv_thread_t default_threads[4]` デフォルトスレッド配列
- E-07: `src/threadpool.c:204-206` - `ARRAY_SIZE(default_threads)` デフォルトスレッド数参照
- E-08: `src/threadpool.c:213-217` - atoi/nthreadsの補正ロジック（0→1、>MAX→MAX）
- E-09: `src/threadpool.c:383-384` - `work_cb == NULL`チェックとUV_EINVAL返却
- E-10: `src/threadpool.c:399-426` - uv_cancelのswitchによるリクエストタイプ振り分け
- E-11: `src/threadpool.c:292-316` - uv__work_cancelの実装（cancelled判定、UV_EBUSY返却）
- E-12: `src/threadpool.c:319-356` - uv__work_doneのメトリクス更新ロジック
- E-13: `src/thread-common.c:38-82` - カスタムバリア実装（AIX/OpenBSD/非pthread_barrier環境）
- E-14: `src/thread-common.c:44-50` - barrierとcountのNULL/0チェック
- E-15: `src/thread-common.c:85-120` - uv_barrier_waitの同期ロジック（in/out/threshold制御）
- E-16: `src/thread-common.c:123-149` - uv_barrier_destroyのクリーンアップとassert
- E-17: `src/threadpool.c:57-140` - workerスレッド関数の実装
- E-18: `src/threadpool.c:143-161` - post関数のキュー投入ロジック
- E-19: `src/threadpool.c:168-191` - uv__threadpool_cleanup関数
- E-20: `src/threadpool.c:241-242` - スタックサイズ設定（config.stack_size = 8u << 20）
- E-21: `src/threadpool.c:256-259` - reset_once関数（Unix固有）
- E-22: `src/threadpool.c:263-273` - init_once関数（pthread_atfork登録）
- E-23: `src/threadpool.c:45-47` - slow_work_thread_threshold関数

## 3) Claims と根拠の対応（レビューの主戦場）
| Claim ID | 主張 | Evidence | 状態 |
|---|---|---|---|
| C-01 | uv_barrier_initはbarrier=有効, count>0で0を返す | E-01, E-13, E-14 | ○ |
| C-02 | uv_barrier_initはcount=1でも成功する | E-01, E-13 | ○ |
| C-03 | uv_barrier_initはbarrier=NULLでUV_EINVALを返す | E-14 (L44, L49) | ○ |
| C-04 | uv_barrier_initはcount=0でUV_EINVALを返す | E-14 (L44, L49) | ○ |
| C-05 | uv_barrier_initはcount=UINT_MAXで成功またはエラー | E-13 | △ |
| C-06 | Unix環境でuv__malloc失敗時にUV_ENOMEMを返す | E-13 (L52-54) | ○ |
| C-07 | mutex初期化失敗時にエラーを返しメモリ解放する | E-13 (L62-63, L76-81) | ○ |
| C-08 | cond初期化失敗時にmutexを破棄しエラーを返す | E-13 (L66-68, L75-81) | ○ |
| C-09 | 全スレッドがバリア到達で解放される | E-15 (L104-112) | ○ |
| C-10 | シリアルスレッドのみが1を返す | E-15 (L114, L119) | ○ |
| C-11 | count=1で即座に返る | E-15 (L104-107) | ○ |
| C-12 | バリアが再利用可能である | E-15 (L101-102, L104-107) | ○ |
| C-13 | barrier=NULLでUV_EINVALを返す（wait） | E-15 (L93-94) | ○ |
| C-14 | バリアが正常に破棄される | E-16 | ○ |
| C-15 | 破棄後barrier->b=NULL（Unix） | E-16 (L146-148) | ○ |
| C-16 | b->in!=0でabortが呼ばれる | E-16 (L134, L138-139) | ○ |
| C-17 | slow_work_thread_thresholdの偶数計算 | E-23 | ○ |
| C-18 | slow_work_thread_thresholdの奇数計算 | E-23 | ○ |
| C-19 | slow_work_thread_thresholdの最小値計算 | E-23 | ○ |
| C-20 | デフォルトスレッド数は4 | E-06, E-07 | ○ |
| C-21 | UV_THREADPOOL_SIZE環境変数でスレッド数を設定可能 | E-08 (L207-213) | ○ |
| C-22 | UV_THREADPOOL_SIZE=0でnthreads=1に補正 | E-08 (L214-215) | ○ |
| C-23 | UV_THREADPOOL_SIZE=1でnthreads=1 | E-08 | ○ |
| C-24 | UV_THREADPOOL_SIZE=1024で最大値 | E-05, E-08 | ○ |
| C-25 | UV_THREADPOOL_SIZE=1025で1024に制限 | E-05, E-08 (L216-217) | ○ |
| C-26 | nthreads<=4でdefault_threads使用 | E-06, E-07 (L219-220) | ○ |
| C-27 | nthreads>4で動的メモリ確保 | E-02 (L220-221) | ○ |
| C-28 | 動的メモリ確保失敗時にフォールバック | E-02 (L222-225) | ○ |
| C-29 | スタックサイズが8MBに設定される | E-20 | ○ |
| C-30 | uv__work_submitがワークを正しく投入する | E-02 (L276-286) | ○ |
| C-31 | UV__WORK_SLOW_IOがスローIOキューに投入される | E-18 (L145-155) | ○ |
| C-32 | 初回呼び出しでスレッドプールが自動初期化される | E-02 (L281) | ○ |
| C-33 | UV__WORK_CPUがメインキューに追加される | E-18 (L157) | ○ |
| C-34 | UV__WORK_SLOW_IOがスローIOキューに追加される | E-18 (L147) | ○ |
| C-35 | アイドルスレッドがある場合にcond_signalされる | E-18 (L158-159) | ○ |
| C-36 | run_slow_work_messageの重複防止 | E-18 (L148-153) | ○ |
| C-37 | workerがワークを取り出して実行する | E-17 (L81-123) | ○ |
| C-38 | exit_messageでworkerが終了する | E-17 (L82-86) | ○ |
| C-39 | スローIO閾値内で実行される | E-17 (L95-106) | ○ |
| C-40 | スローIO閾値超過で再スケジュールされる | E-17 (L95-97) | ○ |
| C-41 | スローIOキュー空でスキップされる | E-17 (L102-103) | ○ |
| C-42 | 完了後にw->work=NULL | E-17 (L126) | ○ |
| C-43 | 完了後にuv_async_sendが呼ばれる | E-17 (L129) | ○ |
| C-44 | ワーカースレッド名が"libuv-worker"に設定される | E-17 (L62) | ○ |
| C-45 | キューに存在するワークがキャンセル可能 | E-11 (L299-301) | ○ |
| C-46 | 実行中ワークのキャンセルでUV_EBUSY | E-11 (L299, L306-307) | ○ |
| C-47 | 完了済みワークのキャンセルでUV_EBUSY | E-11 (L299) | ○ |
| C-48 | キャンセル後にloop->wqに追加される | E-11 (L309-313) | ○ |
| C-49 | 完了ワークのdoneコールバックが呼ばれる | E-12 (L340) | ○ |
| C-50 | キャンセル済みワークにUV_ECANCELED | E-12 (L339) | ○ |
| C-51 | 複数ワークが一括処理される | E-12 (L334-342) | ○ |
| C-52 | 空キューでメトリクス更新なし | E-12 (L350) | ○ |
| C-53 | nevents>1でメトリクス更新 | E-12 (L350-355) | ○ |
| C-54 | current_timeout==0でevents_waiting更新 | E-12 (L353-354) | ○ |
| C-55 | uv__queue_workがwork_cbを呼ぶ | E-02 (L359-363) | ○ |
| C-56 | uv__queue_doneがafter_work_cbを呼ぶ | E-02 (L366-376) | ○ |
| C-57 | after_work_cb=NULLで安全に返る | E-02 (L372-373) | ○ |
| C-58 | リクエストがループから登録解除される | E-02 (L370) | ○ |
| C-59 | uv_queue_workが正常に投入される | E-02 (L379-396), E-09 | ○ |
| C-60 | work_cb=NULLでUV_EINVAL | E-09 (L383-384) | ○ |
| C-61 | after_work_cb=NULLでも投入可能 | E-02 (L379-396) | ○ |
| C-62 | リクエスト型がUV_WORKに設定される | E-02 (L386) | ○ |
| C-63 | UV__WORK_CPUタイプで投入される | E-02 (L390-394) | ○ |
| C-64 | UV_WORKのキャンセル | E-10 (L420-422) | ○ |
| C-65 | UV_FSのキャンセル | E-10 (L404-406) | ○ |
| C-66 | UV_GETADDRINFOのキャンセル | E-10 (L408-410) | ○ |
| C-67 | UV_GETNAMEINFOのキャンセル | E-10 (L411-413) | ○ |
| C-68 | UV_RANDOMのキャンセル | E-10 (L416-418) | ○ |
| C-69 | 未対応タイプでUV_EINVAL | E-10 (L424-425) | ○ |
| C-70 | 実行中リクエストでUV_EBUSY | E-11 | ○ |
| C-71 | スレッドプールの正常クリーンアップ | E-19 | ○ |
| C-72 | nthreads==0で何もしない | E-19 (L171-172) | ○ |
| C-73 | 動的配列がfreeされる | E-19 (L183-184) | ○ |
| C-74 | デフォルト配列はfreeされない | E-19 (L183) | ○ |
| C-75 | クリーンアップ後threads=NULL, nthreads=0 | E-19 (L189-190) | ○ |
| C-76 | pthread_atforkでreset_once登録 | E-22 (L269) | ○ |
| C-77 | init_onceがinit_threadsを呼ぶ | E-22 (L272) | ○ |
| C-78 | fork後にonce変数が再初期化される | E-21 | △ |

## 4) 不足情報（Unknown / Missing）
- **UT-THR-005（C-05）**: count=UINT_MAXでの実際の挙動はプラットフォーム依存。pthread_barrier_init実装では制限がある可能性があるが、libuvコード内に明確な上限チェックはない。カスタム実装（AIX/OpenBSD）では threshold に設定されるのみ
  - 候補：pthreadのドキュメント / POSIX仕様 / 各プラットフォームの制限値
- **UT-THR-016（C-16）**: assert(b->in == 0)とif (b->in != 0) abort()の関係。assertはデバッグビルドのみで有効だが、abort()は常に有効。Release/Debugビルドの違いでの動作確認が必要
  - 候補：libuvのビルド設定 / assertマクロの定義
- **UT-THR-029（C-29）**: 8MBスタックサイズの妥当性について外部仕様書がない。ハードコードされた値
  - 候補：Node.jsドキュメント / libuv設計文書
- **UT-THR-078（C-78）**: fork後のonce再初期化のテストは実環境でのfork操作が必要であり、単体テストでの検証が困難
  - 候補：libuvのforkテスト / POSIXのpthread_atfork仕様

## 5) リスクフラグ（レビュー観点）
- **リスク1 (中リスク)**: スレッドプールのスレッド数に関するテストは環境変数に依存するため、テスト環境のセットアップに注意が必要
- **リスク0 (低リスク)**: バリア関連のテストはプラットフォームによって異なる実装パス（カスタム実装 vs pthread_barrier）が使われるため、テストカバレッジが実行環境に依存する
- **リスク1 (中リスク)**: worker関数内のスローIO制御ロジックは並行実行が前提であり、単体テストでの再現が困難な箇所がある
- **リスク0 (低リスク)**: uv_cancelのリクエストタイプ振り分けは網羅的だが、各リクエストタイプの内部構造に依存するためモック化が必要

## 6) レビュアーチェックリスト（最小）
- [ ] バリア関連テスト（UT-THR-001〜016）が正常系・異常系・境界値を網羅しているか
- [ ] スレッドプール初期化テスト（UT-THR-020〜029）がUV_THREADPOOL_SIZEの全ての分岐を網羅しているか
- [ ] uv_queue_work/uv_cancelのテスト（UT-THR-059〜070）がパブリックAPIの全引数パターンをカバーしているか
- [ ] workerスレッド内のスローIO制御ロジック（UT-THR-039〜043）が並行実行を考慮しているか
- [ ] プラットフォーム固有のコードパス（Unix/Windows分岐）がテストケースで明示されているか
- [ ] メトリクス更新ロジック（UT-THR-052〜054）の境界条件が妥当か
