[インデックス 11879] ファイルの概要

コミット

このコミットは、Goランタイムにおけるシグナルハンドリング、特にSIGQUITシグナル（通常、Ctrl+\によって生成される）の処理方法に関する重要な改善を導入しています。以前のGoランタイムでは、SIGQUITがプロセス内の複数のスレッドに同時に配送されると、複数のスレッドがそれぞれパニック処理を開始しようとする可能性がありました。これにより、不必要な処理の重複や、場合によっては競合状態が発生し、ランタイムの安定性やパニック情報の出力に問題が生じる可能性がありました。

この変更の目的は、SIGQUITのようなプロセス全体に影響を与えるシグナルが受信された際に、Goランタイムが確実に単一のスレッドのみでパニック処理を開始するようにすることです。具体的には、既存のruntime·panickingフラグとruntime·exitの直接呼び出しを、runtime·startpanic()という新しい（または既存の）統一されたパニック開始関数に置き換えることで、この問題を解決しています。これにより、パニック処理の開始がアトミックかつ協調的に行われるようになり、ランタイムの堅牢性が向上します。

GitHub上でのコミットページへのリンク

https://github.com/golang/go/commit/55a54691f931db749e8ddb399b4a55880fa8c642

元コミット内容

runtime: use startpanic so that only one thread handles an incoming SIGQUIT

Typing ^\ delivers the SIGQUIT to all threads, it appears.

R=golang-dev, r, iant
CC=golang-dev
https://golang.org/cl/5657044

変更の背景

このコミットが行われた背景には、GoプログラムがSIGQUITシグナルを受信した際の挙動に関する問題がありました。SIGQUITは、Unix系システムにおいてプロセスを終了させるためのシグナルの一つで、通常はコアダンプを生成してデバッグに役立てる目的で使用されます。しかし、マルチスレッド環境では、SIGQUITのようなシグナルがプロセス内の全てのスレッドに配送されることがあります。

Goランタイムは、シグナルを受信すると、そのシグナルに対応するハンドラ（この場合はruntime·sighandler）を呼び出します。問題は、複数のスレッドが同時にSIGQUITを受信し、それぞれがパニック処理を開始しようとすると、runtime·panickingフラグのチェックと設定、そしてruntime·exitの呼び出しが競合状態に陥る可能性があったことです。

具体的には、

1. スレッドAがSIGQUITを受信し、runtime·sighandler内でruntime·panickingが0であることを確認し、1に設定しようとする。
2. ほぼ同時にスレッドBもSIGQUITを受信し、同様にruntime·panickingが0であることを確認する。
3. スレッドAがruntime·panickingを1に設定する。
4. スレッドBもruntime·panickingを1に設定しようとする（または、スレッドAが設定した1を読み取ってruntime·exit(2)を呼び出す）。

この競合により、複数のスレッドがパニックトレースバックを出力したり、runtime·exitを複数回呼び出したりする可能性があり、これは望ましくない挙動でした。特に、トレースバックが複数回出力されると、デバッグ情報の可読性が損なわれるだけでなく、ランタイムの内部状態が不安定になるリスクもありました。

このコミットは、このような競合状態を解消し、SIGQUITによるパニック処理が常に単一の、協調的な方法で開始されるようにするために導入されました。

前提知識の解説

1. UnixシグナルとSIGQUIT

Unix系オペレーティングシステムでは、シグナルはプロセスに対して非同期的にイベントを通知するメカニズムです。シグナルには様々な種類があり、それぞれ異なるイベントに対応しています。

• SIGQUIT: プロセスに終了を要求するシグナルの一つです。通常、ユーザーがターミナルでCtrl+\を押すことで生成されます。SIGINT（Ctrl+C）がプロセスを「中断」するのに対し、SIGQUITはより強制的な終了を意図し、多くの場合、プロセスのコアダンプを生成します。コアダンプは、プログラムがクラッシュした時点のメモリ状態を記録したファイルで、デバッグに非常に役立ちます。

2. マルチスレッド環境におけるシグナル配送

マルチスレッドプログラムにおいてシグナルがどのように配送されるかは、シグナルの種類やOSの実装によって異なります。

• プロセスワイドシグナル: SIGQUITのような一部のシグナルは、プロセス全体に配送されます。これは、シグナルが特定の単一スレッドではなく、プロセス全体に関連するイベント（例: ユーザーからの終了要求）を示すためです。
• スレッドへの配送: プロセスワイドシグナルが配送された場合、通常はプロセス内のいずれかのスレッドがそのシグナルを処理します。しかし、実装によっては、複数のスレッドが同時にシグナルを受信し、それぞれがシグナルハンドラを実行しようとする可能性があります。これが、Goランタイムで問題となっていた「複数のスレッドがSIGQUITを受信し、それぞれパニック処理を開始しようとする」状況を引き起こしていました。

3. Goランタイムのパニックとシグナルハンドリング

Go言語には、プログラムの異常終了を扱うための「パニック (panic)」というメカニズムがあります。パニックが発生すると、通常の実行フローが中断され、遅延関数（defer）が実行され、最終的にプログラムが終了します。

• runtime·panicking: Goランタイム内部で使用されるフラグで、ランタイムが現在パニック状態にあるかどうかを示します。このフラグは、パニック処理が重複して行われるのを防ぐために使用されます。
• runtime·exit(code): Goランタイム内部で、プログラムを終了させるために使用される関数です。引数codeは終了ステータスを示します。
• runtime·sighandler: GoランタイムがOSからのシグナルを受信した際に呼び出される内部関数です。この関数内で、受信したシグナルに応じた処理（例えば、SIGQUITの場合はパニックの開始）が行われます。
• runtime·startpanic(): このコミットで導入または利用が強化されたGoランタイム内部の関数です。その名の通り、パニック処理を「開始」するための統一されたエントリポイントとして機能します。この関数は、複数のスレッドから同時に呼び出されても、パニック処理が一度だけ、かつ安全に開始されるように内部で同期メカニズム（例えば、アトミック操作やミューテックス）を持っていると推測されます。

技術的詳細

このコミットの技術的な核心は、GoランタイムがSIGQUITシグナルを受信した際のパニック開始ロジックを、スレッドセーフかつアトミックなruntime·startpanic()関数に集約した点にあります。

変更前のコードでは、runtime·sighandler関数内でSIGQUIT（またはその他の致命的なシグナル）が検出された場合、以下のようなロジックでパニック処理を開始していました。

Throw:
    if(runtime·panicking)    // traceback already printed
        runtime·exit(2);
    runtime·panicking = 1;
    // ... その他のパニック処理 ...

このコードの問題点は、runtime·panickingフラグのチェックと設定がアトミックではないことです。複数のスレッドが同時にThrow:ラベルに到達した場合、以下のような競合状態が発生する可能性がありました。

1. スレッドAがif(runtime·panicking)を評価し、false（まだパニック中でない）と判断する。
2. OSがスレッドAの実行を中断し、スレッドBに切り替える。
3. スレッドBもif(runtime·panicking)を評価し、falseと判断する。
4. スレッドBがruntime·panicking = 1;を実行し、パニック状態を設定する。
5. スレッドBがruntime·exit(2);を呼び出し、プログラムを終了させようとする。
6. OSがスレッドBの実行を中断し、スレッドAに切り替える。
7. スレッドAがruntime·panicking = 1;を実行する（既に1になっているかもしれないが、問題はない）。
8. スレッドAもパニック処理を続行し、トレースバックを出力したり、runtime·exit(2);を呼び出したりする。

このシナリオでは、runtime·exit(2)が複数回呼び出される可能性があり、これはシステムコールレベルでの問題を引き起こす可能性があります。また、パニックトレースバックが重複して出力されることも考えられます。

このコミットでは、この脆弱なロジックをruntime·startpanic()の単一呼び出しに置き換えることで、問題を解決しています。

Throw:
    runtime·startpanic();

runtime·startpanic()関数は、Goランタイムの内部で実装されており、以下のような特性を持つと推測されます。

• アトミックなパニック状態の遷移: runtime·startpanic()の内部では、パニック状態への遷移（例えば、runtime·panickingフラグの設定）がアトミックに行われるように、適切な同期プリミティブ（例: スピンロック、ミューテックス、またはアトミック操作）が使用されていると考えられます。これにより、複数のスレッドが同時にこの関数を呼び出しても、パニック処理は一度だけ、かつ安全に開始されます。
• 単一のパニック処理フロー: runtime·startpanic()は、パニック処理の開始を調整し、トレースバックの生成やプログラムの終了といった後続の処理が、単一の制御フローによって行われるようにします。これにより、重複したトレースバックの出力や、runtime·exitの多重呼び出しが防止されます。
• プラットフォーム非依存性: この変更が複数のOS（Darwin, FreeBSD, Linux, NetBSD, OpenBSD）およびアーキテクチャ（386, amd64）のシグナルハンドラファイルに適用されていることから、runtime·startpanic()はGoランタイムのコア部分で実装されており、プラットフォームに依存しない形でパニック開始ロジックを抽象化していることがわかります。

この変更により、GoプログラムがSIGQUITのようなシグナルを受信した際のパニック処理がより堅牢になり、マルチスレッド環境での予期せぬ挙動が抑制されます。

コアとなるコードの変更箇所

このコミットは、Goランタイムのシグナルハンドリングに関連する以下の10個のファイルに影響を与えています。

• src/pkg/runtime/signal_darwin_386.c
• src/pkg/runtime/signal_darwin_amd64.c
• src/pkg/runtime/signal_freebsd_386.c
• src/pkg/runtime/signal_freebsd_amd64.c
• src/pkg/runtime/signal_linux_386.c
• src/pkg/runtime/signal_linux_amd64.c
• src/pkg/runtime/signal_netbsd_386.c
• src/pkg/runtime/signal_netbsd_amd64.c
• src/pkg/runtime/signal_openbsd_386.c
• src/pkg/runtime/signal_openbsd_amd64.c

これらのファイルは、それぞれ特定のOSとアーキテクチャにおけるGoランタイムのシグナルハンドラの実装を含んでいます。

各ファイルにおいて、runtime·sighandler関数内のThrow:ラベルに続くコードブロックが変更されています。

変更前:

Throw:
    if(runtime·panicking)    // traceback already printed
        runtime·exit(2);
    runtime·panicking = 1;

変更後:

Throw:
    runtime·startpanic();

コアとなるコードの解説

変更されたコードは、Goランタイムが致命的なシグナル（例: SIGQUIT）を受信し、パニック処理を開始する必要があると判断した際の挙動を定義しています。

変更前のコードの課題:

変更前のコードでは、Throw:ラベルに到達すると、まずruntime·panickingというグローバルフラグをチェックしていました。

• もしruntime·panickingが既に1（パニック中）であれば、それは既にトレースバックが出力されていることを意味するため、runtime·exit(2)を呼び出してプログラムを終了していました。これは、複数のシグナルがほぼ同時に到着した場合に、重複してパニック処理が行われるのを防ぐための試みでした。
• もしruntime·panickingが0（パニック中でない）であれば、runtime·panicking = 1;を設定してパニック状態に入り、その後のパニック処理（トレースバックの生成など）に進んでいました。

しかし、このif(runtime·panicking)のチェックとruntime·panicking = 1;の設定は、アトミックな操作ではありませんでした。そのため、前述の「変更の背景」や「技術的詳細」で説明したように、複数のスレッドが同時にこのコードパスを実行しようとすると、競合状態が発生し、意図しない挙動（例: 複数回のruntime·exit呼び出し、重複したトレースバック）を引き起こす可能性がありました。

変更後のコードの利点:

変更後のコードでは、この競合状態の発生源となっていたロジックを、単一の関数呼び出しruntime·startpanic()に置き換えています。

runtime·startpanic()は、Goランタイムの内部で実装された、パニック処理を安全かつアトミックに開始するための統一されたエントリポイントです。この関数は、内部で適切な同期メカニズム（例えば、アトミック操作やミューテックス）を使用して、複数のスレッドから同時に呼び出されても、パニック処理が一度だけ、かつ正しく開始されることを保証します。

これにより、SIGQUITのようなシグナルが複数のスレッドに配送された場合でも、Goランタイムは確実に単一のパニック処理フローを開始し、システムの安定性とデバッグ情報の正確性を保つことができます。この変更は、Goランタイムの堅牢性と信頼性を向上させる上で重要な改善と言えます。

関連リンク

• Go言語の公式ドキュメント: https://golang.org/doc/
• Goのランタイムに関する議論（golang-devメーリングリストなど）: https://groups.google.com/g/golang-dev
• Goのソースコードリポジトリ: https://github.com/golang/go

参考にした情報源リンク

• コミット情報から得られたGo CL (Change List) のリンク: https://golang.org/cl/5657044
• Unixシグナルに関する一般的な情報源 (例: man pages, POSIX標準)
• マルチスレッドプログラミングにおけるシグナルハンドリングに関する情報源
• Goランタイムの内部構造に関する一般的な知識 (Goのソースコードリーディングや関連する技術記事)
• Google検索 (golang runtime SIGQUIT, golang runtime panicking, golang runtime startpanic, unix signal handling multithreaded SIGQUIT)# [インデックス 11879] ファイルの概要

コミット

このコミットは、Goランタイムにおけるシグナルハンドリング、特にSIGQUITシグナル（通常、Ctrl+\によって生成される）の処理方法に関する重要な改善を導入しています。以前のGoランタイムでは、SIGQUITがプロセス内の複数のスレッドに同時に配送されると、複数のスレッドがそれぞれパニック処理を開始しようとする可能性がありました。これにより、不必要な処理の重複や、場合によっては競合状態が発生し、ランタイムの安定性やパニック情報の出力に問題が生じる可能性がありました。

この変更の目的は、SIGQUITのようなプロセス全体に影響を与えるシグナルが受信された際に、Goランタイムが確実に単一のスレッドのみでパニック処理を開始するようにすることです。具体的には、既存のruntime·panickingフラグとruntime·exitの直接呼び出しを、runtime·startpanic()という新しい（または既存の）統一されたパニック開始関数に置き換えることで、この問題を解決しています。これにより、パニック処理の開始がアトミックかつ協調的に行われるようになり、ランタイムの堅牢性が向上します。

GitHub上でのコミットページへのリンク

https://github.com/golang/go/commit/55a54691f931db749e8ddb399b4a55880fa8c642

元コミット内容

commit 55a54691f931db749e8ddb399b4a55880fa8c642
Author: Russ Cox <rsc@golang.org>
Date:   Mon Feb 13 23:06:21 2012 -0500

    runtime: use startpanic so that only one thread handles an incoming SIGQUIT
    
    Typing ^\ delivers the SIGQUIT to all threads, it appears.
    
    R=golang-dev, r, iant
    CC=golang-dev
    https://golang.org/cl/5657044
---
 src/pkg/runtime/signal_darwin_386.c    | 4 +---\n src/pkg/runtime/signal_darwin_amd64.c  | 4 +---\n src/pkg/runtime/signal_freebsd_386.c   | 4 +---\n src/pkg/runtime/signal_freebsd_amd64.c | 4 +---\n src/pkg/runtime/signal_linux_386.c     | 4 +---\n src/pkg/runtime/signal_linux_amd64.c   | 4 +---\n src/pkg/runtime/signal_netbsd_386.c    | 4 +---\n src/pkg/runtime/signal_netbsd_amd64.c   | 4 +---\n src/pkg/runtime/signal_openbsd_386.c   | 4 +---\n src/pkg/runtime/signal_openbsd_amd64.c | 4 +---\n 10 files changed, 10 insertions(+), 30 deletions(-)

diff --git a/src/pkg/runtime/signal_darwin_386.c b/src/pkg/runtime/signal_darwin_386.c
index 803bd242f3..1844f68a63 100644
--- a/src/pkg/runtime/signal_darwin_386.c
+++ b/src/pkg/runtime/signal_darwin_386.c
@@ -92,9 +92,7 @@ runtime·sighandler(int32 sig, Siginfo *info, void *context, G *gp)
 		return;
 
 Throw:
-	if(runtime·panicking)	// traceback already printed
-		runtime·exit(2);
-	runtime·panicking = 1;
+	runtime·startpanic();
 
 	if(sig < 0 || sig >= NSIG){
 		runtime·printf("Signal %d\n", sig);
diff --git a/src/pkg/runtime/signal_darwin_amd64.c b/src/pkg/runtime/signal_darwin_amd64.c
index 0c954294a5..32c73081c1 100644
--- a/src/pkg/runtime/signal_darwin_amd64.c
+++ b/src/pkg/runtime/signal_darwin_amd64.c
@@ -102,9 +102,7 @@ runtime·sighandler(int32 sig, Siginfo *info, void *context, G *gp)
 		return;
 
 Throw:
-	if(runtime·panicking)	// traceback already printed
-		runtime·exit(2);
-	runtime·panicking = 1;
+	runtime·startpanic();
 
 	if(sig < 0 || sig >= NSIG){
 		runtime·printf("Signal %d\n", sig);
diff --git a/src/pkg/runtime/signal_freebsd_386.c b/src/pkg/runtime/signal_freebsd_386.c
index b07ead62e8..80da95d98a 100644
--- a/src/pkg/runtime/signal_freebsd_386.c
+++ b/src/pkg/runtime/signal_freebsd_386.c
@@ -89,9 +89,7 @@ runtime·sighandler(int32 sig, Siginfo *info, void *context, G *gp)
 		return;
 
 Throw:
-	if(runtime·panicking)	// traceback already printed
-		runtime·exit(2);
-	runtime·panicking = 1;
+	runtime·startpanic();
 
 	if(sig < 0 || sig >= NSIG)
 		runtime·printf("Signal %d\n", sig);
diff --git a/src/pkg/runtime/signal_freebsd_amd64.c b/src/pkg/runtime/signal_freebsd_amd64.c
index 2a68609681..e4307682f4 100644
--- a/src/pkg/runtime/signal_freebsd_amd64.c
+++ b/src/pkg/runtime/signal_freebsd_amd64.c
@@ -97,9 +97,7 @@ runtime·sighandler(int32 sig, Siginfo *info, void *context, G *gp)
 		return;
 
 Throw:
-	if(runtime·panicking)	// traceback already printed
-		runtime·exit(2);
-	runtime·panicking = 1;
+	runtime·startpanic();
 
 	if(sig < 0 || sig >= NSIG)
 		runtime·printf("Signal %d\\n", sig);\ndiff --git a/src/pkg/runtime/signal_linux_386.c b/src/pkg/runtime/signal_linux_386.c
index b43dbc1121..b154ad8872 100644
--- a/src/pkg/runtime/signal_linux_386.c
+++ b/src/pkg/runtime/signal_linux_386.c
@@ -85,9 +85,7 @@ runtime·sighandler(int32 sig, Siginfo *info, void *context, G *gp)
 		return;
 
 Throw:
-	if(runtime·panicking)	// traceback already printed
-		runtime·exit(2);
-	runtime·panicking = 1;
+	runtime·startpanic();
 
 	if(sig < 0 || sig >= NSIG)
 		runtime·printf("Signal %d\\n", sig);\ndiff --git a/src/pkg/runtime/signal_linux_amd64.c b/src/pkg/runtime/signal_linux_amd64.c
index 551744b78d..14095ba61c 100644
--- a/src/pkg/runtime/signal_linux_amd64.c
+++ b/src/pkg/runtime/signal_linux_amd64.c
@@ -95,9 +95,7 @@ runtime·sighandler(int32 sig, Siginfo *info, void *context, G *gp)
 		return;
 
 Throw:
-	if(runtime·panicking)	// traceback already printed
-		runtime·exit(2);
-	runtime·panicking = 1;
+	runtime·startpanic();
 
 	if(sig < 0 || sig >= NSIG)
 		runtime·printf("Signal %d\\n", sig);\ndiff --git a/src/pkg/runtime/signal_netbsd_386.c b/src/pkg/runtime/signal_netbsd_386.c
index 739b359ee6..39d829484d 100644
--- a/src/pkg/runtime/signal_netbsd_386.c
+++ b/src/pkg/runtime/signal_netbsd_386.c
@@ -85,9 +85,7 @@ runtime·sighandler(int32 sig, Siginfo *info, void *context, G *gp)
 		return;
 
 Throw:
-	if(runtime·panicking)	// traceback already printed
-		runtime·exit(2);
-	runtime·panicking = 1;
+	runtime·startpanic();
 
 	if(sig < 0 || sig >= NSIG)
 		runtime·printf("Signal %d\\n", sig);\ndiff --git a/src/pkg/runtime/signal_netbsd_amd64.c b/src/pkg/runtime/signal_netbsd_amd64.c
index e71f23551d..8b4f624e7c 100644
--- a/src/pkg/runtime/signal_netbsd_amd64.c
+++ b/src/pkg/runtime/signal_netbsd_amd64.c
@@ -94,9 +94,7 @@ runtime·sighandler(int32 sig, Siginfo *info, void *context, G *gp)
 		return;
 
 Throw:
-	if(runtime·panicking)	// traceback already printed
-		runtime·exit(2);
-	runtime·panicking = 1;
+	runtime·startpanic();
 
 	if(sig < 0 || sig >= NSIG)
 		runtime·printf("Signal %d\\n", sig);\ndiff --git a/src/pkg/runtime/signal_openbsd_386.c b/src/pkg/runtime/signal_openbsd_386.c
index 739b359ee6..39d829484d 100644
--- a/src/pkg/runtime/signal_openbsd_386.c
+++ b/src/pkg/runtime/signal_openbsd_386.c
@@ -85,9 +85,7 @@ runtime·sighandler(int32 sig, Siginfo *info, void *context, G *gp)
 		return;
 
 Throw:
-	if(runtime·panicking)	// traceback already printed
-		runtime·exit(2);
-	runtime·panicking = 1;
+	runtime·startpanic();
 
 	if(sig < 0 || sig >= NSIG)
 		runtime·printf("Signal %d\\n", sig);\ndiff --git a/src/pkg/runtime/signal_openbsd_amd64.c b/src/pkg/runtime/signal_openbsd_amd64.c
index e71f23551d..8b4f624e7c 100644
--- a/src/pkg/runtime/signal_openbsd_amd64.c
+++ b/src/pkg/runtime/signal_openbsd_amd64.c
@@ -94,9 +94,7 @@ runtime·sighandler(int32 sig, Siginfo *info, void *context, G *gp)
 		return;
 
 Throw:
-	if(runtime·panicking)	// traceback already printed
-		runtime·exit(2);
-	runtime·panicking = 1;
+	runtime·startpanic();
 
 	if(sig < 0 || sig >= NSIG)
 		runtime·printf("Signal %d\\n", sig);

変更の背景

このコミットが行われた背景には、GoプログラムがSIGQUITシグナルを受信した際の挙動に関する問題がありました。SIGQUITは、Unix系システムにおいてプロセスを終了させるためのシグナルの一つで、通常はコアダンプを生成してデバッグに役立てる目的で使用されます。しかし、マルチスレッド環境では、SIGQUITのようなシグナルがプロセス内の全てのスレッドに配送されることがあります。

Goランタイムは、シグナルを受信すると、そのシグナルに対応するハンドラ（この場合はruntime·sighandler）を呼び出します。問題は、複数のスレッドが同時にSIGQUITを受信し、それぞれがパニック処理を開始しようとすると、runtime·panickingフラグのチェックと設定、そしてruntime·exitの呼び出しが競合状態に陥る可能性があったことです。

具体的には、

1. スレッドAがSIGQUITを受信し、runtime·sighandler内でruntime·panickingが0であることを確認し、1に設定しようとする。
2. ほぼ同時にスレッドBもSIGQUITを受信し、同様にruntime·panickingが0であることを確認する。
3. スレッドAがruntime·panickingを1に設定する。
4. スレッドBもruntime·panickingを1に設定しようとする（または、スレッドAが設定した1を読み取ってruntime·exit(2)を呼び出す）。

この競合により、複数のスレッドがパニックトレースバックを出力したり、runtime·exitを複数回呼び出したりする可能性があり、これは望ましくない挙動でした。特に、トレースバックが複数回出力されると、デバッグ情報の可読性が損なわれるだけでなく、ランタイムの内部状態が不安定になるリスクもありました。

このコミットは、このような競合状態を解消し、SIGQUITによるパニック処理が常に単一の、協調的な方法で開始されるようにするために導入されました。

前提知識の解説

1. UnixシグナルとSIGQUIT

Unix系オペレーティングシステムでは、シグナルはプロセスに対して非同期的にイベントを通知するメカニズムです。シグナルには様々な種類があり、それぞれ異なるイベントに対応しています。

• SIGQUIT: プロセスに終了を要求するシグナルの一つです。通常、ユーザーがターミナルでCtrl+\を押すことで生成されます。SIGINT（Ctrl+C）がプロセスを「中断」するのに対し、SIGQUITはより強制的な終了を意図し、多くの場合、プロセスのコアダンプを生成します。コアダンプは、プログラムがクラッシュした時点のメモリ状態を記録したファイルで、デバッグに非常に役立ちます。

2. マルチスレッド環境におけるシグナル配送

マルチスレッドプログラムにおいてシグナルがどのように配送されるかは、シグナルの種類やOSの実装によって異なります。

• プロセスワイドシグナル: SIGQUITのような一部のシグナルは、プロセス全体に配送されます。これは、シグナルが特定の単一スレッドではなく、プロセス全体に関連するイベント（例: ユーザーからの終了要求）を示すためです。
• スレッドへの配送: プロセスワイドシグナルが配送された場合、通常はプロセス内のいずれかのスレッドがそのシグナルを処理します。しかし、実装によっては、複数のスレッドが同時にシグナルを受信し、それぞれがシグナルハンドラを実行しようとする可能性があります。これが、Goランタイムで問題となっていた「複数のスレッドがSIGQUITを受信し、それぞれパニック処理を開始しようとする」状況を引き起こしていました。

3. Goランタイムのパニックとシグナルハンドリング

Go言語には、プログラムの異常終了を扱うための「パニック (panic)」というメカニズムがあります。パニックが発生すると、通常の実行フローが中断され、遅延関数（defer）が実行され、最終的にプログラムが終了します。

• runtime·panicking: Goランタイム内部で使用されるフラグで、ランタイムが現在パニック状態にあるかどうかを示します。このフラグは、パニック処理が重複して行われるのを防ぐために使用されます。
• runtime·exit(code): Goランタイム内部で、プログラムを終了させるために使用される関数です。引数codeは終了ステータスを示します。
• runtime·sighandler: GoランタイムがOSからのシグナルを受信した際に呼び出される内部関数です。この関数内で、受信したシグナルに応じた処理（例えば、SIGQUITの場合はパニックの開始）が行われます。
• runtime·startpanic(): このコミットで導入または利用が強化されたGoランタイム内部の関数です。その名の通り、パニック処理を「開始」するための統一されたエントリポイントとして機能します。この関数は、複数のスレッドから同時に呼び出されても、パニック処理が一度だけ、かつ安全に開始されるように内部で同期メカニズム（例えば、アトミック操作やミューテックス）を持っていると推測されます。

技術的詳細

このコミットの技術的な核心は、GoランタイムがSIGQUITシグナルを受信した際のパニック開始ロジックを、スレッドセーフかつアトミックなruntime·startpanic()関数に集約した点にあります。

変更前のコードでは、runtime·sighandler関数内でSIGQUIT（またはその他の致命的なシグナル）が検出された場合、以下のようなロジックでパニック処理を開始していました。

Throw:
    if(runtime·panicking)    // traceback already printed
        runtime·exit(2);
    runtime·panicking = 1;
    // ... その他のパニック処理 ...

このコードの問題点は、runtime·panickingフラグのチェックと設定がアトミックではないことです。複数のスレッドが同時にThrow:ラベルに到達した場合、以下のような競合状態が発生する可能性がありました。

1. スレッドAがif(runtime·panicking)を評価し、false（まだパニック中でない）と判断する。
2. OSがスレッドAの実行を中断し、スレッドBに切り替える。
3. スレッドBもif(runtime·panicking)を評価し、falseと判断する。
4. スレッドBがruntime·panicking = 1;を実行し、パニック状態を設定する。
5. スレッドBがruntime·exit(2);を呼び出し、プログラムを終了させようとする。
6. OSがスレッドBの実行を中断し、スレッドAに切り替える。
7. スレッドAがruntime·panicking = 1;を実行する（既に1になっているかもしれないが、問題はない）。
8. スレッドAもパニック処理を続行し、トレースバックを出力したり、runtime·exit(2);を呼び出したりする。

このシナリオでは、runtime·exit(2)が複数回呼び出される可能性があり、これはシステムコールレベルでの問題を引き起こす可能性があります。また、パニックトレースバックが重複して出力されることも考えられます。

このコミットでは、この脆弱なロジックをruntime·startpanic()の単一呼び出しに置き換えることで、問題を解決しています。

Throw:
    runtime·startpanic();

runtime·startpanic()関数は、Goランタイムの内部で実装されており、以下のような特性を持つと推測されます。

• アトミックなパニック状態の遷移: runtime·startpanic()の内部では、パニック状態への遷移（例えば、runtime·panickingフラグの設定）がアトミックに行われるように、適切な同期プリミティブ（例: スピンロック、ミューテックス、またはアトミック操作）が使用されていると考えられます。これにより、複数のスレッドが同時にこの関数を呼び出しても、パニック処理は一度だけ、かつ安全に開始されます。
• 単一のパニック処理フロー: runtime·startpanic()は、パニック処理の開始を調整し、トレースバックの生成やプログラムの終了といった後続の処理が、単一の制御フローによって行われるようにします。これにより、重複したトレースバックの出力や、runtime·exitの多重呼び出しが防止されます。
• プラットフォーム非依存性: この変更が複数のOS（Darwin, FreeBSD, Linux, NetBSD, OpenBSD）およびアーキテクチャ（386, amd64）のシグナルハンドラファイルに適用されていることから、runtime·startpanic()はGoランタイムのコア部分で実装されており、プラットフォームに依存しない形でパニック開始ロジックを抽象化していることがわかります。

この変更により、GoプログラムがSIGQUITのようなシグナルを受信した際のパニック処理がより堅牢になり、マルチスレッド環境での予期せぬ挙動が抑制されます。

コアとなるコードの変更箇所

このコミットは、Goランタイムのシグナルハンドリングに関連する以下の10個のファイルに影響を与えています。

• src/pkg/runtime/signal_darwin_386.c
• src/pkg/runtime/signal_darwin_amd64.c
• src/pkg/runtime/signal_freebsd_386.c
• src/pkg/runtime/signal_freebsd_amd64.c
• src/pkg/runtime/signal_linux_386.c
• src/pkg/runtime/signal_linux_amd64.c
• src/pkg/runtime/signal_netbsd_386.c
• src/pkg/runtime/signal_netbsd_amd64.c
• src/pkg/runtime/signal_openbsd_386.c
• src/pkg/runtime/signal_openbsd_amd64.c

これらのファイルは、それぞれ特定のOSとアーキテクチャにおけるGoランタイムのシグナルハンドラの実装を含んでいます。

各ファイルにおいて、runtime·sighandler関数内のThrow:ラベルに続くコードブロックが変更されています。

変更前:

Throw:
    if(runtime·panicking)    // traceback already printed
        runtime·exit(2);
    runtime·panicking = 1;

変更後:

Throw:
    runtime·startpanic();

コアとなるコードの解説

変更されたコードは、Goランタイムが致命的なシグナル（例: SIGQUIT）を受信し、パニック処理を開始する必要があると判断した際の挙動を定義しています。

変更前のコードの課題:

変更前のコードでは、Throw:ラベルに到達すると、まずruntime·panickingというグローバルフラグをチェックしていました。

• もしruntime·panickingが既に1（パニック中）であれば、それは既にトレースバックが出力されていることを意味するため、runtime·exit(2)を呼び出してプログラムを終了していました。これは、複数のシグナルがほぼ同時に到着した場合に、重複してパニック処理が行われるのを防ぐための試みでした。
• もしruntime·panickingが0（パニック中でない）であれば、runtime·panicking = 1;を設定してパニック状態に入り、その後のパニック処理（トレースバックの生成など）に進んでいました。

しかし、このif(runtime·panicking)のチェックとruntime·panicking = 1;の設定は、アトミックな操作ではありませんでした。そのため、前述の「変更の背景」や「技術的詳細」で説明したように、複数のスレッドが同時にこのコードパスを実行しようとすると、競合状態が発生し、意図しない挙動（例: 複数回のruntime·exit呼び出し、重複したトレースバック）を引き起こす可能性がありました。

変更後のコードの利点:

変更後のコードでは、この競合状態の発生源となっていたロジックを、単一の関数呼び出しruntime·startpanic()に置き換えています。

runtime·startpanic()は、Goランタイムの内部で実装された、パニック処理を安全かつアトミックに開始するための統一されたエントリポイントです。この関数は、内部で適切な同期メカニズム（例えば、アトミック操作やミューテックス）を使用して、複数のスレッドから同時に呼び出されても、パニック処理が一度だけ、かつ正しく開始されることを保証します。

これにより、SIGQUITのようなシグナルが複数のスレッドに配送された場合でも、Goランタイムは確実に単一のパニック処理フローを開始し、システムの安定性とデバッグ情報の正確性を保つことができます。この変更は、Goランタイムの堅牢性と信頼性を向上させる上で重要な改善と言えます。

関連リンク

• Go言語の公式ドキュメント: https://golang.org/doc/
• Goのランタイムに関する議論（golang-devメーリングリストなど）: https://groups.google.com/g/golang-dev
• Goのソースコードリポジトリ: https://github.com/golang/go

参考にした情報源リンク

• コミット情報から得られたGo CL (Change List) のリンク: https://golang.org/cl/5657044
• Unixシグナルに関する一般的な情報源 (例: man pages, POSIX標準)
• マルチスレッドプログラミングにおけるシグナルハンドリングに関する情報源
• Goランタイムの内部構造に関する一般的な知識 (Goのソースコードリーディングや関連する技術記事)
• Google検索 (golang runtime SIGQUIT, golang runtime panicking, golang runtime startpanic, unix signal handling multithreaded SIGQUIT)