シグナル配送の内部とシグナルセーフティ

なぜ「配送タイミング」を知る必要があるのか

シグナルの基礎（シグナル）では「合図を1つ送る非同期通知」だと説明しました。しかし実務でシグナル絡みの障害——ハンドラ内のデッドロック、取りこぼし、EINTR の謎——を解くには、シグナルがいつ・どこで・どう配送されるかという内部機構を正確に押さえる必要があります。本記事は、生成（generate）と配送（deliver）の分離、ブロックマスク、シグナルフレーム、そして async-signal-safety の根拠を原理から解剖します。

生成と配送は別物：ペンディング集合とブロックマスク

シグナルのライフサイクルは2段階に分かれます。

• 生成（generation）：kill() やハードウェア例外などでシグナルが発生し、対象タスクの ペンディング集合（pending set） に記録された状態。
• 配送（delivery）：そのシグナルに対応する動作（ハンドラ実行・既定動作・無視）が実際に行われる瞬間。

この2つの間に時間差が生まれるのは、各タスクが ブロックマスク（signal mask、sigprocmask で操作） を持つからです。マスクされたシグナルは、生成されてもペンディングのまま 保留 され、マスクが解かれて初めて配送されます。

kill(pid, SIGUSR1)
   │
   ▼  生成：pending集合に SIGUSR1 を立てる
[pending] ── マスク中？ ──Yes──→ 保留（マスク解除まで待機）
   │ No
   ▼  配送：ハンドラ/既定動作を実行し、pendingから降ろす

カーネル内では、ペンディング集合もブロックマスクも sigset_t（ビットマップ）で表現され、シグナル番号 n はビット n に対応します。つまり「SIGUSR1 が保留中か」は単なるビットテストです。

配送はいつ起きるか：カーネル→ユーザー空間の境界

ハンドラは「実行中のどのタイミングでも割り込む」と言われますが、厳密には任意の機械語命令の途中で割り込むわけではありません。配送が起きるのは、カーネルからユーザー空間へ制御が戻る境界 です。具体的には次のような瞬間です。

• システムコール（システムコール）から復帰するとき
• 割り込み・例外処理からユーザーモードへ戻るとき
• タイムスライス満了などでスケジューラ経由でタスクが再開するとき

カーネルはこの戻り際に「配送可能な（pending かつ非マスク）シグナルはあるか」をチェックし（do_signal 系の処理）、あればユーザー空間へ戻る前にハンドラを差し込みます。だから純粋にユーザー空間で無限ループしているプロセスにも、タイマー割り込みでカーネルに入る隙があるため配送できます。

この「戻り境界で配送」という設計が、有名な EINTR の正体です。read() 等でブロック中にハンドラ付きシグナルが届くと、カーネルはシステムコールを中断してハンドラを呼び、システムコールは errno = EINTR で返ります（SA_RESTART 指定時は自動再開）。

ssize_t n;
while ((n = read(fd, buf, len)) < 0 && errno == EINTR)
    ;  // EINTR は「失敗」ではない。ループで再試行するのが定石

シグナルフレーム：スタックに積まれる「割り込みの記録」

ハンドラを呼ぶには、現在のユーザーコンテキスト（レジスタ・元の戻り先・配送時のブロックマスク）を保存しておき、ハンドラ終了後に元の処理へ正確に戻る必要があります。カーネルはこれを シグナルフレーム として ユーザースタック上に構築 します。

1. カーネルが、割り込まれた地点のレジスタ一式と元のマスクを ucontext 構造としてユーザースタックへ積む。
2. ハンドラの戻り先を トランポリン（sigreturn を呼ぶ小片コード）に差し替え、ハンドラへジャンプする。
3. ハンドラが return すると、トランポリンが sigreturn システムコールを発行する。
4. sigreturn がフレームから元のコンテキストを復元し、割り込まれた地点へ正確に復帰する。

[ユーザースタック]
  ┌────────────┐ ← ハンドラ実行中はここから下が積まれる
  │ シグナルフレーム │  保存されたレジスタ・元マスク・戻り先(トランポリン)
  ├────────────┤
  │ 割り込まれた地点 │  ← sigreturn でここへ戻る

スタックが壊れている状況（SIGSEGV をスタックオーバーフローで受けた等）でも配送できるよう、sigaltstack() で 別スタック（alternate stack） を指定し、SA_ONSTACK で利用できます。スタック破壊系のシグナルを安全に捕まえる定石です。

async-signal-safety：なぜ malloc を呼んではいけないか

ここが上級者の核心です。ハンドラは メインの処理と同じスレッドの、任意の地点へ割り込んで 実行されます。割り込まれたコードが malloc の途中でヒープのロックを保持していたら、その同じスレッドのハンドラ内で再び malloc を呼ぶと——自分が握ったロックの解放を自分で待つデッドロック が起きます。

この問題の本質は 再入可能性（re-entrancy） です。ハンドラから安全に呼べるのは、内部状態やロックを共有せず、途中で割り込まれて再入されても壊れない関数——すなわち async-signal-safe な関数だけです。POSIX/Linux は安全な関数の一覧を signal-safety(7) で明示的に列挙しており、そこに無い関数（malloc/free/printf 系/std::cout/大半の stdio/ロケール依存関数など）は呼んではいけません。

実務での定石は 「ハンドラはフラグを立てるだけ」 です。volatile sig_atomic_t なフラグを 1 にするか、signalfd/self-pipe で通知し、重い処理はメインループに戻ってから行います。

volatile sig_atomic_t got_term = 0;
void on_term(int sig) { got_term = 1; }  // これだけ。printf も free も書かない
// メインループで if (got_term) { graceful_shutdown(); } を見る

標準シグナル vs リアルタイムシグナル

標準シグナル（1〜31）には2つの本質的制約があります。同種のシグナルが複数生成されても1個に潰れる（合体される） こと、そして 配送順序が保証されない ことです。ペンディング集合がビットマップである以上、「SIGUSR1 が来た」という1ビットしか立たず、何回来たかは数えられません。

リアルタイムシグナル（SIGRTMIN 〜 SIGRTMAX、Linux では通常 32〜64）はこれを解消します。

• キューイングされる：同じ番号が複数届いても潰れず、生成順に並んで全部配送される（上限あり）。
• 値を運べる：sigqueue() で int または void* を siginfo_t->si_value に添えられる。シグナルでデータを運べる唯一の正攻法。
• 番号間の順序：小さい番号が先に配送される（優先度がある）。

signalfd：非同期シグナルを同期イベントへ

ハンドラ方式の根本的な不自由さは「async-signal-safe の檻」です。これを回避するのが signalfd() です。シグナルをハンドラで非同期に受ける代わりに、ファイルディスクリプタからの読み取りという同期イベント に変換します。

sigset_t m; sigemptyset(&m); sigaddset(&m, SIGTERM);
sigprocmask(SIG_BLOCK, &m, NULL);   // 通常配送を止めるのが前提
int sfd = signalfd(-1, &m, 0);
// 以降 read(sfd, &si, sizeof(struct signalfd_siginfo)) でシグナルを受け取る

要点は、対象シグナルを 必ずブロックしておく ことです。ブロックしてペンディングに溜め、それを signalfd から読み出します。この fd は epoll で監視できる（高性能I/Oモデル（epoll・io_uring）の内部）ため、シグナルを通常の I/O イベントと同じイベントループで一元処理 できます。ハンドラの再入制約から解放され、read 後の文脈では malloc でも何でも自由に呼べるのが最大の利点です。

同系統に、sigwaitinfo/sigtimedwait（専用スレッドでブロックして同期受信）や、タイマー・ファイル変更を fd 化する timerfd/inotify があり、いずれも「非同期イベントを fd の同期読み取りに統一する」Linux の設計思想を体現しています。デバッガがシグナルを横取りして観測する仕組みは ptrace とデバッグの内部 も参照してください。

まとめ