---
title: SQLite ライタースレッドの死活監視におけるポーリング間隔の維持
status: Accepted
date: 2026-02-24
context: Reliability of Background Write Operations
---

# SQLite ライタースレッドの死活監視におけるポーリング間隔の維持

## Context and Problem Statement / コンテキスト

`SQLiteTaskDB` は、専用のライタースレッドを用いて書き込みを直列化しています。メインスレッドが書き込み完了を待機する際（または `flush` 実行時）、ライタースレッドが予期せず死亡（セグメンテーションフォールトや深刻なエラー等）した場合に、メインスレッドが永久にハングアップするのを防ぐ必要があります。

## Decision Drivers / 要求

* **Liveness**: ライタースレッドが異常終了した場合でも、メインスレッドがそれを検知して確実に解放されること。
* **Zero Latency (Normal Case)**: 正常な動作時において、監視ロジックが書き込み完了の通知を遅延させないこと。
* **Efficiency**: 待機中の CPU リソースや電力の浪費を抑えること。
* **Simplicity**: デッドロックのリスクを避け、実装を簡潔に保つこと。

## Considered Options / 検討

* **Option 1**: 純粋なイベントベースの通知。ライタースレッドが通知前に死亡するとメインスレッドが永久にハングする。
* **Option 2**: 極端に短い間隔（0.01秒等）でのポーリング。CPU リソースを浪費する。
* **Option 3**: バランスの取れた間隔（0.5秒）でのポーリングと、スレッドの生存確認（`is_alive()`）を組み合わせる。

## Decision Outcome / 決定

Chosen option: **Option 3**.

0.5 秒というポーリング間隔を維持し、ループ内で `task.event.wait(timeout=0.5)` とスレッドの生存確認を行う設計を継続します。

1. **安全装置**: ライタースレッドが異常終了しても、最大 0.5 秒以内に異常を検知してメインスレッドを解放できます。
2. **正常系パフォーマンス**: `threading.Event.wait` はイベントがセットされた瞬間に即座に復帰するため、正常な書き込み時には 0.5 秒という数値はレイテンシに一切影響しません。
3. **リソース効率**: 間隔を適切に保つことで、不要なコンテキストスイッチや CPU 浪費を防ぎます。

## Consequences / 決定

* **Positive**:
    * 実装が簡潔でデッドロックのリスクが低く、かつスレッド死亡時にも確実にリカバリできる。
    * 正常系のパフォーマンスを一切損なうことなく、異常系への耐性を獲得できる。
* **Negative**:
    * スレッドが死亡した際、異常を認識するまでに最大 0.5 秒のタイムラグが発生する。しかし、稀な異常事態におけるこの程度の遅延は許容範囲内である。
