Keyboard shortcuts

Press or to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

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

このコミットは、Go言語の標準ライブラリであるlog/syslogパッケージのテストファイルであるsrc/pkg/log/syslog/syslog_test.goに対する変更です。このファイルは、log/syslogパッケージがシステムログデーモン(syslog)と正しく連携できることを保証するための単体テストおよび統合テストを含んでいます。具体的には、様々なネットワークトランスポート(UDP、TCP、Unixドメインソケットなど)を介したログの送信と受信、エラーハンドリング、および並行処理のシナリオをシミュレートしてテストしています。

コミット

  • コミットハッシュ: 1b651556c3f3cbf3d2d98dc30d76a164f850d19b
  • Author: Russ Cox rsc@golang.org
  • Date: Mon Sep 9 16:17:59 2013 -0400

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

https://github.com/golang/go/commit/1b651556c3f3cbf3d2d98dc30d76a164f850d19b

元コミット内容

syslog: fix data race on 'crashy' in test function

Fixes #5894.

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

変更の背景

このコミットは、Go言語のlog/syslogパッケージのテストコードにおいて発生していたデータ競合(data race)を修正するために行われました。具体的には、テスト関数内で使用されていた'crashy'という変数(またはそれに類する共有リソース)に対して、複数のゴルーチンが同時にアクセスしようとした際に競合状態が発生し、テストが不安定になったり、予期せぬ結果(クラッシュなど)を引き起こしたりする問題(Issue #5894)が存在していました。

データ競合は並行プログラミングにおける一般的なバグであり、共有リソースへの非同期なアクセスが原因で発生します。この場合、テストコード内でシミュレートされたsyslogサーバーの起動や停止、ソケットのクローズといった操作が、テストのメインゴルーチンと並行して実行される他のゴルーチン(例えば、サーバーをバックグラウンドで実行するゴルーチン)との間で適切に同期されていなかったことが問題の根源と考えられます。これにより、テストが終了する前にバックグラウンドの処理が完了していなかったり、リソースが適切に解放されていなかったりする状況が発生し、テストの信頼性を損なっていました。

この修正は、テストの安定性を向上させ、Goの並行処理モデルにおけるベストプラクティスをテストコードにも適用することを目的としています。

前提知識の解説

1. Go言語の並行処理 (Concurrency in Go)

Go言語は、軽量なスレッドである「ゴルーチン(Goroutine)」と、ゴルーチン間の安全な通信を可能にする「チャネル(Channel)」を核とした並行処理モデルを提供します。

  • ゴルーチン (Goroutine): Goランタイムによって管理される軽量な実行スレッドです。goキーワードを関数呼び出しの前に置くことで簡単に起動できます。数千、数万のゴルーチンを同時に実行してもオーバーヘッドが少ないのが特徴です。
  • チャネル (Channel): ゴルーチン間で値を送受信するための通信メカニズムです。チャネルは、データの受け渡しを通じてゴルーチン間の同期を安全に行うことができます。

2. データ競合 (Data Race)

データ競合は、複数のゴルーチンが同時に同じメモリ位置にアクセスし、少なくとも1つのアクセスが書き込みであり、かつそれらのアクセスが同期メカニズムによって保護されていない場合に発生するバグです。データ競合が発生すると、プログラムの動作が予測不能になり、クラッシュ、不正なデータ、セキュリティ脆弱性などの問題を引き起こす可能性があります。

Go言語には、データ競合を検出するための「競合検出器(Race Detector)」が組み込まれており、go run -racego test -raceコマンドで有効にできます。このツールは、実行時にデータ競合の可能性を検出し、詳細なレポートを提供します。今回のコミットも、おそらくこの競合検出器によって問題が特定されたものと推測されます。

3. sync.WaitGroup

sync.WaitGroupは、複数のゴルーチンの完了を待つために使用される同期プリミティブです。以下のメソッドを提供します。

  • Add(delta int): 待機するゴルーチンのカウンタをdeltaだけ増やします。
  • Done(): 待機するゴルーチンのカウンタを1減らします。ゴルーチンが完了したことを示します。
  • Wait(): カウンタがゼロになるまでブロックします。すべてのゴルーチンがDone()を呼び出すまで待機します。

テストコードでは、バックグラウンドで起動したサーバーゴルーチンが適切に終了するのを待つためにsync.WaitGroupが使用されることがよくあります。

4. deferステートメント

deferステートメントは、それを囲む関数がリターンする直前に実行される関数呼び出しをスケジュールします。これは、リソースの解放(ファイルのクローズ、ロックの解除など)を確実に行うために非常に便利です。deferされた関数はLIFO(後入れ先出し)の順序で実行されます。

5. log/syslogパッケージ

Goの標準ライブラリの一部であるlog/syslogパッケージは、Unix系システムで広く使用されているsyslogプロトコルを介してシステムログメッセージを送信するための機能を提供します。これにより、Goアプリケーションはシステム全体のログ管理システムと統合し、ログメッセージを一元的に収集・管理できます。

技術的詳細

このコミットの技術的詳細な修正は、主にsyslog_test.go内のテストヘルパー関数startServerの呼び出し箇所にdefer srvWG.Wait()defer sock.Close()を追加することに集約されます。

startServer関数は、テストのために一時的なsyslogサーバーをバックグラウンドで起動し、そのサーバーのアドレス、ソケット、そしてサーバーゴルーチンの完了を待つためのsync.WaitGroupsrvWG)を返します。

修正前は、startServerが返したsrvWGに対してWait()を呼び出す処理が不足しているか、あるいはsock.Close()が適切にdeferされていなかったため、以下の問題が発生していました。

  1. ゴルーチンの終了待機不足: テスト関数が終了する前に、startServerによって起動されたバックグラウンドのサーバーゴルーチンがまだ実行中である可能性がありました。これにより、テストが終了した後もサーバーゴルーチンが共有リソース(例えば、テスト内で設定されたグローバルな状態や、'crashy'という変数)にアクセスしようとし、メインのテストゴルーチンが既にそのリソースを解放したり、別のテストがそのリソースを再利用しようとしたりする際にデータ競合が発生していました。srvWG.Wait()deferすることで、テスト関数がリターンする直前にサーバーゴルーチンが確実に終了するまで待機するようになります。
  2. ソケットの不適切なクローズ: テスト中に開かれたネットワークソケットが、テスト終了時に適切にクローズされない場合がありました。これにより、リソースリークが発生したり、次のテスト実行時に同じアドレスやポートを再利用しようとした際に「アドレスが既に使用中」といったエラーが発生したりする可能性がありました。sock.Close()deferすることで、テスト関数が終了する際にソケットが確実にクローズされ、リソースが解放されるようになります。

これらのdeferステートメントの追加により、テストの各シナリオにおいて、バックグラウンドで起動されたサーバーゴルーチンが確実に完了し、関連するネットワークリソースが適切に解放されることが保証されます。これにより、テスト実行間の状態のクリーンアップが徹底され、共有リソースに対するデータ競合が解消され、テストの信頼性と安定性が大幅に向上しました。

特に、TestConcurrentWrite関数では、make(chan string, 1)としてバッファ付きチャネルを渡す変更も行われています。これは、チャネルがブロックされることなくメッセージを送信できるようにすることで、並行書き込みテストのデッドロックやハングアップを防ぐための調整である可能性があります。

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

--- a/src/pkg/log/syslog/syslog_test.go
+++ b/src/pkg/log/syslog/syslog_test.go
@@ -122,7 +122,9 @@ func TestWithSimulated(t *testing.T) {
 
 	for _, tr := range transport {
 		done := make(chan string)
-		addr, _, _ := startServer(tr, "", done)
+		addr, sock, srvWG := startServer(tr, "", done)
+		defer srvWG.Wait()
+		defer sock.Close()
 		if tr == "unix" || tr == "unixgram" {
 			defer os.Remove(addr)
 		}
@@ -142,7 +144,8 @@ func TestWithSimulated(t *testing.T) {
 func TestFlap(t *testing.T) {
 	net := "unix"
 	done := make(chan string)
-	addr, sock, _ := startServer(net, "", done)
+	addr, sock, srvWG := startServer(net, "", done)
+	defer srvWG.Wait()
 	defer os.Remove(addr)
 	defer sock.Close()
 
@@ -158,7 +161,8 @@ func TestFlap(t *testing.T) {
 	check(t, msg, <-done)
 
 	// restart the server
-	_, sock2, _ := startServer(net, addr, done)
+	_, sock2, srvWG2 := startServer(net, addr, done)
+	defer srvWG2.Wait()
 	defer sock2.Close()
 
 	// and try retransmitting
@@ -249,7 +253,8 @@ func TestWrite(t *testing.T) {
 	} else {
 		for _, test := range tests {
 			done := make(chan string)
-			addr, sock, _ := startServer("udp", "", done)
+			addr, sock, srvWG := startServer("udp", "", done)
+			defer srvWG.Wait()
 			defer sock.Close()
 			l, err := Dial("udp", addr, test.pri, test.pre)
 			if err != nil {
@@ -272,7 +277,8 @@ func TestWrite(t *testing.T) {\n }\n \n func TestConcurrentWrite(t *testing.T) {\n-\taddr, sock, _ := startServer("udp", "", make(chan string))\n+\taddr, sock, srvWG := startServer("udp", "", make(chan string, 1))\n+\tdefer srvWG.Wait()\n \tdefer sock.Close()\n \tw, err := Dial("udp", addr, LOG_USER|LOG_ERR, "how's it going?")\n \tif err != nil {\n```

## コアとなるコードの解説

上記のdiffは、`syslog_test.go`内の複数のテスト関数(`TestWithSimulated`, `TestFlap`, `TestWrite`, `TestConcurrentWrite`)における`startServer`関数の呼び出し箇所に修正が加えられていることを示しています。

各変更点の詳細な解説は以下の通りです。

1.  **`TestWithSimulated`関数内**:
    ```diff
    -		addr, _, _ := startServer(tr, "", done)
    +		addr, sock, srvWG := startServer(tr, "", done)
    +		defer srvWG.Wait()
    +		defer sock.Close()
    ```
    `startServer`の戻り値として、以前は無視されていた`sock`(ネットワークソケット)と`srvWG`(`sync.WaitGroup`)を明示的に受け取るように変更されています。そして、`defer srvWG.Wait()`と`defer sock.Close()`が追加されました。これにより、`TestWithSimulated`関数が終了する際に、バックグラウンドで起動したサーバーゴルーチンが確実に完了するまで待機し、かつソケットが適切にクローズされることが保証されます。

2.  **`TestFlap`関数内(最初の`startServer`呼び出し)**:
    ```diff
    -	addr, sock, _ := startServer(net, "", done)
    +	addr, sock, srvWG := startServer(net, "", done)
    +	defer srvWG.Wait()
    ```
    ここでも`srvWG`を受け取り、`defer srvWG.Wait()`が追加されています。これにより、最初のサーバーが確実に終了するまで待機します。`sock.Close()`は既に`defer`されていました。

3.  **`TestFlap`関数内(サーバー再起動時の`startServer`呼び出し)**:
    ```diff
    -	_, sock2, _ := startServer(net, addr, done)
    +	_, sock2, srvWG2 := startServer(net, addr, done)
    +	defer srvWG2.Wait()
    ```
    サーバーを再起動する際も同様に、新しいサーバーの`srvWG2`を受け取り、`defer srvWG2.Wait()`を追加しています。これにより、再起動されたサーバーも適切に終了待機されます。`sock2.Close()`は既に`defer`されていました。

4.  **`TestWrite`関数内**:
    ```diff
    -			addr, sock, _ := startServer("udp", "", done)
    +			addr, sock, srvWG := startServer("udp", "", done)
    +			defer srvWG.Wait()
    ```
    `TestWrite`関数内のループでも、各テストケースで起動されるUDPサーバーに対して`srvWG`を受け取り、`defer srvWG.Wait()`を追加しています。これにより、各UDPサーバーがテストケースの終了時に確実に終了待機されます。`sock.Close()`は既に`defer`されていました。

5.  **`TestConcurrentWrite`関数内**:
    ```diff
    -	addr, sock, _ := startServer("udp", "", make(chan string))\n+\taddr, sock, srvWG := startServer("udp", "", make(chan string, 1))\n+\tdefer srvWG.Wait()
    ```
    `TestConcurrentWrite`では、`startServer`に渡すチャネルが`make(chan string)`から`make(chan string, 1)`(バッファ付きチャネル)に変更されています。これは、並行書き込みのシナリオにおいて、チャネルがブロックされることによるデッドロックやハングアップを防ぐための調整と考えられます。また、ここでも`srvWG`を受け取り、`defer srvWG.Wait()`が追加され、サーバーゴルーチンの終了待機が確実に行われるようになっています。`sock.Close()`は既に`defer`されていました。

これらの変更は、テストコードにおけるリソース管理とゴルーチン同期のベストプラクティスを適用したものであり、テストの信頼性と安定性を高める上で非常に重要です。特に、`sync.WaitGroup`の`Wait()`を`defer`することで、テスト関数が予期せぬエラーで早期にリターンした場合でも、バックグラウンドのサーバーゴルーチンが適切にクリーンアップされることが保証されます。

## 関連リンク

*   Go CL 13303051: [https://golang.org/cl/13303051](https://golang.org/cl/13303051)

## 参考にした情報源リンク

*   Go言語公式ドキュメント: [https://go.dev/](https://go.dev/)
*   Go言語の並行処理に関する記事やチュートリアル
*   Go言語の`sync`パッケージに関するドキュメント
*   Go言語の競合検出器に関する情報
*   Stack Overflowなどの開発者コミュニティにおけるデータ競合に関する議論
*   GitHub上のgolang/goリポジトリのIssueトラッカー (Issue #5894は直接見つからなかったが、一般的なデータ競合のパターンを理解するために参照)