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

このコミットは、Goランタイムの src/pkg/runtime/proc.c ファイルに対するリファクタリングです。主な変更は、ローカル変数名の g を gp に、m を mp に変更すること、およびホワイトスペースの調整です。これらの変更はセマンティックな変更を含まず、将来のより大きな変更に備えるための準備作業として位置づけられています。

コミット

commit a0c688331f095126d8a079c249903e4a6728581f
Author: Dmitriy Vyukov <dvyukov@google.com>
Date:   Tue Jul 3 12:54:13 2012 +0400

    runtime: refactor proc.c
    1. Rename 'g' and 'm' local vars to 'gp' and 'mp' (convention already used in some functions)
    'g' and 'm' are global vars that mean current goroutine and current machine,
    when they are shadowed by local vars, it's confusing, no ability to debug log both, etc.
    2. White-space shuffling.
    No semantic changes.
    In preparation to bigger changes.
    
    R=golang-dev, dave
    CC=golang-dev
    https://golang.org/cl/6355061

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

https://github.com/golang/go/commit/a0c688331f095126d8a079c249903e4a6728581f

元コミット内容

Goランタイムの proc.c ファイルをリファクタリングしました。

ローカル変数 g と m を gp と mp にリネームしました（一部の関数では既にこの命名規則が使用されています）。 g と m は、現在のゴルーチンと現在のマシンを意味するグローバル変数です。これらがローカル変数によってシャドウされると、混乱を招き、両方をデバッグログに出力できないなどの問題がありました。
ホワイトスペースの調整を行いました。セマンティックな変更はありません。より大きな変更に備えるための準備です。

変更の背景

このコミットの背景には、Goランタイムの可読性と保守性の向上という明確な目的があります。特に、Goのスケジューラはゴルーチン（G）、論理プロセッサ（P）、OSスレッド（M）という3つの主要なエンティティを管理しており、これらのエンティティを表す変数名の一貫性はコードの理解に不可欠です。

コミットメッセージに明記されているように、g と m はGoランタイム全体で「現在のゴルーチン」と「現在のマシン（OSスレッド）」を指すグローバル変数として使用されています。しかし、関数内で同じ名前のローカル変数が宣言されると、そのローカル変数がグローバル変数を「シャドウ」してしまい、コードを読む際にどちらの g や m を指しているのかが不明瞭になります。これは、特にデバッグ時において、グローバルな状態とローカルな状態を同時に追跡することが困難になるという問題を引き起こします。

この混乱を解消し、コードの意図をより明確にするために、ローカル変数には gp（goroutine pointer）と mp（machine pointer）という接尾辞を付けて、それがポインタであり、かつローカルなスコープでゴルーチンやマシンを指していることを明確にする命名規則が採用されました。この変更は、単なる変数名のリネームに過ぎませんが、Goランタイムのような複雑なシステムにおいては、コードの理解度と将来の拡張性、そしてデバッグの容易さに大きく貢献します。

また、「In preparation to bigger changes.（より大きな変更に備えるための準備）」という記述から、このリファクタリングが、Goランタイムのスケジューラやメモリ管理など、より根幹的な部分への将来的な機能追加や改善のための土台作りであることが示唆されます。クリーンで一貫性のあるコードベースは、大規模な変更を安全かつ効率的に導入するための前提条件となります。

前提知識の解説

このコミットを理解するためには、以下のGoランタイムに関する前提知識が必要です。

Goランタイムとスケジューラ

Goは独自のランタイムとスケジューラを持っています。これは、OSのスケジューラとは独立して、GoのゴルーチンをOSスレッドにマッピングし、実行を管理する役割を担います。Goのスケジューラは、G-M-Pモデルとして知られる設計に基づいています。

G (Goroutine): Goにおける軽量な実行単位です。OSスレッドよりもはるかに軽量で、数百万個のゴルーチンを同時に実行できます。Goの関数呼び出しがゴルーチンとして実行されます。
M (Machine / OS Thread): OSが管理する実際のOSスレッドです。Goランタイムは、MをOSに要求し、その上でGを実行します。Mは、システムコールやブロッキング操作が発生した場合に、他のGの実行を妨げないように切り離されることがあります。
P (Processor / Context): 論理プロセッサ、またはコンテキストとも呼ばれます。GとMを仲介する役割を担います。Pは、実行可能なGのキューを保持し、MにGを割り当てて実行させます。Pの数は通常、CPUのコア数に設定され、並列実行の度合いを制御します。

Goスケジューラは、GをPにディスパッチし、PがMにGを実行させるという流れで動作します。このモデルにより、Goは高い並行性と効率的なリソース利用を実現しています。

`proc.c` の役割

src/pkg/runtime/proc.c は、Goランタイムの心臓部の一つであり、G-M-Pモデルにおけるゴルーチン、マシン、プロセッサの管理とスケジューリングに関する低レベルなロジックが実装されています。具体的には、ゴルーチンの生成、スケジューリングキューへの追加、実行状態の管理、OSスレッドとの連携などがこのファイルで定義されています。C言語で記述されているのは、Goランタイムの非常に低レベルな部分であり、OSとのインタラクションやパフォーマンスが極めて重要であるためです。

変数名のシャドウイング

プログラミングにおいて、変数名の「シャドウイング（shadowing）」とは、内側のスコープで宣言された変数が、外側のスコープで同じ名前を持つ変数を「隠す」現象を指します。このコミットの文脈では、グローバルスコープで宣言された g（現在のゴルーチン）や m（現在のマシン）といった変数が、関数などのローカルスコープで同じ名前のローカル変数によって隠されてしまうことを指します。

シャドウイング自体は言語仕様上許容されることが多いですが、特に大規模なコードベースやデバッグが必要な場面では、どの変数を参照しているのかが曖昧になり、混乱やバグの原因となることがあります。このコミットは、このような混乱を避けるために、ローカル変数に明確な命名規則を適用することで、コードの可読性と保守性を向上させています。

技術的詳細

このコミットは、Goランタイムの src/pkg/runtime/proc.c ファイルにおける変数名の変更とホワイトスペースの調整に焦点を当てています。

変数名の変更 (`g` -> `gp`, `m` -> `mp`)

対象変数: G 型のローカル変数 g と M 型のローカル変数 m。
変更理由:
- グローバル変数との衝突: Goランタイムには、現在のゴルーチンを指すグローバル変数 g と、現在のOSスレッド（マシン）を指すグローバル変数 m が存在します。これらのグローバル変数は、ランタイムの様々な場所で暗黙的に参照されることがあります。
- シャドウイングによる混乱: 関数内で同じ名前のローカル変数 g や m が宣言されると、その関数内ではグローバル変数がローカル変数によって「シャドウ」され、アクセスできなくなります。これにより、コードを読む人がどの g や m を参照しているのかを判断するのが難しくなり、特にデバッグ時に混乱を招きます。例えば、グローバルな g の状態とローカルな g の状態を同時に確認したい場合、名前が同じだと区別がつきません。
- 命名規則の一貫性: コミットメッセージにあるように、一部の関数では既に gp や mp といった命名規則が採用されていました。今回の変更は、この命名規則を proc.c 全体に適用することで、コードベース全体の命名規則の一貫性を高め、Goランタイムのコードスタイルを統一することを目的としています。
変更の影響: この変更は純粋なリファクタリングであり、コードのセマンティクス（動作）には一切影響を与えません。コンパイル後のバイナリの動作は変更前と全く同じです。

ホワイトスペースの調整

内容: コード内のインデント、改行、スペースなどのホワイトスペースに関する調整。
目的: コードのフォーマットを改善し、可読性を向上させるため。Goプロジェクトでは gofmt などのツールによってコードフォーマットが厳密に管理されていますが、ランタイムのCコード部分では手動での調整が必要な場合もあります。
影響: 変数名のリネームと同様に、コードのセマンティクスには影響を与えません。

将来の変更への準備

コミットメッセージの「In preparation to bigger changes.」という記述は非常に重要です。Goランタイムは継続的に進化しており、新しい機能の追加やパフォーマンスの最適化が頻繁に行われます。このような大規模な変更を行う前に、コードベースを整理し、可読性と保守性を高めるためのリファクタリングは一般的なプラクティスです。

このリファクタリングは、GoランタイムのG-M-Pスケジューリングモデルの核心部分である proc.c に手を入れるものであり、将来的にスケジューラの挙動変更、新しい同期プリミティブの導入、またはメモリ管理の改善など、より複雑な変更が行われる可能性を示唆しています。クリーンな変数名は、これらの複雑な変更を導入する際のバグのリスクを減らし、開発者がコードをより迅速に理解し、変更を安全に適用できるようにするための基盤となります。

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

src/pkg/runtime/proc.c ファイル全体で、G *g と M *m というローカル変数の宣言と使用箇所が、それぞれ G *gp と M *mp に変更されています。

例:

変更前:

void
runtime·goroutineheader(G *g)
{
    int8 *status;

    switch(g->status) {
    // ...
    runtime·printf("goroutine %d [%s]:\n", g->goid, status);
}

変更後:

void
runtime·goroutineheader(G *gp)
{
    int8 *status;

    switch(gp->status) {
    // ...
    runtime·printf("goroutine %d [%s]:\n", gp->goid, status);
}

同様に、M 型のローカル変数 m も mp に変更されています。

変更前:

static void
mcommoninit(M *m)
{
    m->id = runtime·sched.mcount++;
    // ...
    runtime·atomicstorep(&runtime·allm, m);
}

変更後:

static void
mcommoninit(M *mp)
{
    mp->id = runtime·sched.mcount++;
    // ...
    runtime·atomicstorep(&runtime·allm, mp);
}

これらの変更はファイル全体にわたって一貫して適用されており、91行の挿入と91行の削除という差分が示す通り、純粋な変数名のリネームとホワイトスペースの調整のみが行われています。

コアとなるコードの解説

このコミットにおけるコアとなるコードの変更は、Goランタイムの proc.c 内のローカル変数名の変更です。具体的には、ゴルーチンを表すポインタ変数 g を gp に、マシン（OSスレッド）を表すポインタ変数 m を mp に変更しています。

この変更の意義は、コードのセマンティクスを変えることなく、可読性と保守性を大幅に向上させる点にあります。

命名規則の明確化:
- Goランタイムの内部では、g と m という名前が、それぞれ「現在の実行中のゴルーチン」と「現在の実行中のOSスレッド」を指すグローバル変数として頻繁に使用されます。
- 関数内で同じ名前のローカル変数 g や m が宣言されると、そのローカルスコープ内ではグローバル変数が「シャドウ」され、アクセスできなくなります。これにより、コードを読む人が、その g や m がグローバルな現在のゴルーチン/マシンを指しているのか、それとも関数に渡された特定のゴルーチン/マシンを指しているのかを区別するのが困難になります。
- gp（goroutine pointer）と mp（machine pointer）という命名規則を採用することで、これらの変数がポインタであり、かつローカルなスコープで特定のゴルーチンやマシンを指していることが一目で明確になります。これにより、グローバルな g や m との混同が避けられ、コードの意図がより明確になります。
デバッグの容易性:
- シャドウイングが発生している場合、デバッガで g や m の値を検査しようとすると、ローカル変数の方の値しか見ることができません。グローバルな g や m の状態を確認するには、別の手段を講じる必要がありました。
- gp や mp という異なる名前を使用することで、デバッグ時にローカルなゴルーチン/マシンとグローバルなゴルーチン/マシンを明確に区別して追跡することが可能になり、デバッグ作業が格段に容易になります。
将来の変更への準備:
- Goランタイムは非常に複雑なシステムであり、その進化は継続的に行われています。このコミットは、「より大きな変更に備えるための準備」と明記されています。
- コードベースがクリーンで一貫性のある命名規則に従っていることは、将来的に新しい機能を追加したり、既存のロジックを修正したりする際に、バグを導入するリスクを減らし、開発者がコードをより迅速に理解し、安全に変更を加えるための強固な基盤となります。

この変更は、Goランタイムの内部実装の品質と保守性を高めるための、地味ながらも非常に重要なステップと言えます。

参考にした情報源リンク

Go Scheduler: Go's hidden gem: https://www.ardanlabs.com/blog/2018/08/go-scheduler.html (GoスケジューラのG-M-Pモデルに関する解説)
Go's work-stealing scheduler: https://rakyll.org/go-scheduler/ (Goのスケジューラに関する別の解説)
Variable Shadowing in Go: https://yourbasic.org/golang/variable-shadowing/ (Goにおける変数シャドウイングに関する解説)
Goのソースコード (特に src/runtime/proc.go や src/runtime/runtime.go など、スケジューラ関連のファイル)
Goのドキュメント (特にランタイムに関する部分)
Goのコミット履歴とコードレビューシステム (Gerrit)
C言語のポインタと変数スコープに関する一般的な知識I have provided the detailed explanation as requested. I will now output it to standard output.

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

このコミットは、Goランタイムの `src/pkg/runtime/proc.c` ファイルに対するリファクタリングです。主な変更は、ローカル変数名の `g` を `gp` に、`m` を `mp` に変更すること、およびホワイトスペースの調整です。これらの変更はセマンティックな変更を含まず、将来のより大きな変更に備えるための準備作業として位置づけられています。

## コミット

commit a0c688331f095126d8a079c249903e4a6728581f Author: Dmitriy Vyukov dvyukov@google.com Date: Tue Jul 3 12:54:13 2012 +0400

runtime: refactor proc.c
1. Rename 'g' and 'm' local vars to 'gp' and 'mp' (convention already used in some functions)
'g' and 'm' are global vars that mean current goroutine and current machine,
when they are shadowed by local vars, it's confusing, no ability to debug log both, etc.
2. White-space shuffling.
No semantic changes.
In preparation to bigger changes.

R=golang-dev, dave
CC=golang-dev
https://golang.org/cl/6355061


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

[https://github.com/golang/go/commit/a0c688331f095126d8a079c249903e4a6728581f](https://github.com/golang.com/go/commit/a0c688331f095126d8a079c249903e4a6728581f)

## 元コミット内容

Goランタイムの `proc.c` ファイルをリファクタリングしました。
1.  ローカル変数 `g` と `m` を `gp` と `mp` にリネームしました（一部の関数では既にこの命名規則が使用されています）。
    `g` と `m` は、現在のゴルーチンと現在のマシンを意味するグローバル変数です。これらがローカル変数によってシャドウされると、混乱を招き、両方をデバッグログに出力できないなどの問題がありました。
2.  ホワイトスペースの調整を行いました。
セマンティックな変更はありません。
より大きな変更に備えるための準備です。

## 変更の背景

このコミットの背景には、Goランタイムの可読性と保守性の向上という明確な目的があります。特に、Goのスケジューラはゴルーチン（G）、論理プロセッサ（P）、OSスレッド（M）という3つの主要なエンティティを管理しており、これらのエンティティを表す変数名の一貫性はコードの理解に不可欠です。

コミットメッセージに明記されているように、`g` と `m` はGoランタイム全体で「現在のゴルーチン」と「現在のマシン（OSスレッド）」を指すグローバル変数として使用されています。しかし、関数内で同じ名前のローカル変数が宣言されると、そのローカル変数がグローバル変数を「シャドウ」してしまい、コードを読む際にどちらの `g` や `m` を指しているのかが不明瞭になります。これは、特にデバッグ時において、グローバルな状態とローカルな状態を同時に追跡することが困難になるという問題を引き起こします。

この混乱を解消し、コードの意図をより明確にするために、ローカル変数には `gp`（goroutine pointer）と `mp`（machine pointer）という接尾辞を付けて、それがポインタであり、かつローカルなスコープでゴルーチンやマシンを指していることを明確にする命名規則が採用されました。この変更は、単なる変数名のリネームに過ぎませんが、Goランタイムのような複雑なシステムにおいては、コードの理解度と将来の拡張性、そしてデバッグの容易さに大きく貢献します。

また、「In preparation to bigger changes.（より大きな変更に備えるための準備）」という記述から、このリファクタリングが、Goランタイムのスケジューラやメモリ管理など、より根幹的な部分への将来的な機能追加や改善のための土台作りであることが示唆されます。クリーンで一貫性のあるコードベースは、大規模な変更を安全かつ効率的に導入するための前提条件となります。

## 前提知識の解説

このコミットを理解するためには、以下のGoランタイムに関する前提知識が必要です。

### Goランタイムとスケジューラ

Goは独自のランタイムとスケジューラを持っています。これは、OSのスケジューラとは独立して、GoのゴルーチンをOSスレッドにマッピングし、実行を管理する役割を担います。Goのスケジューラは、G-M-Pモデルとして知られる設計に基づいています。

*   **G (Goroutine)**: Goにおける軽量な実行単位です。OSスレッドよりもはるかに軽量で、数百万個のゴルーチンを同時に実行できます。Goの関数呼び出しがゴルーチンとして実行されます。
*   **M (Machine / OS Thread)**: OSが管理する実際のOSスレッドです。Goランタイムは、MをOSに要求し、その上でGを実行します。Mは、システムコールやブロッキング操作が発生した場合に、他のGの実行を妨げないように切り離されることがあります。
*   **P (Processor / Context)**: 論理プロセッサ、またはコンテキストとも呼ばれます。GとMを仲介する役割を担います。Pは、実行可能なGのキューを保持し、MにGを割り当てて実行させます。Pの数は通常、CPUのコア数に設定され、並列実行の度合いを制御します。

Goスケジューラは、GをPにディスパッチし、PがMにGを実行させるという流れで動作します。このモデルにより、Goは高い並行性と効率的なリソース利用を実現しています。

### `proc.c` の役割

`src/pkg/runtime/proc.c` は、Goランタイムの心臓部の一つであり、G-M-Pモデルにおけるゴルーチン、マシン、プロセッサの管理とスケジューリングに関する低レベルなロジックが実装されています。具体的には、ゴルーチンの生成、スケジューリングキューへの追加、実行状態の管理、OSスレッドとの連携などがこのファイルで定義されています。C言語で記述されているのは、Goランタイムの非常に低レベルな部分であり、OSとのインタラクションやパフォーマンスが極めて重要であるためです。

### 変数名のシャドウイング

プログラミングにおいて、変数名の「シャドウイング（shadowing）」とは、内側のスコープで宣言された変数が、外側のスコープで同じ名前を持つ変数を「隠す」現象を指します。このコミットの文脈では、グローバルスコープで宣言された `g`（現在のゴルーチン）や `m`（現在のマシン）といった変数が、関数などのローカルスコープで同じ名前のローカル変数によって隠されてしまうことを指します。

シャドウイング自体は言語仕様上許容されることが多いですが、特に大規模なコードベースやデバッグが必要な場面では、どの変数を参照しているのかが曖昧になり、混乱やバグの原因となることがあります。このコミットは、このような混乱を避けるために、ローカル変数に明確な命名規則を適用することで、コードの可読性と保守性を向上させています。

## 技術的詳細

このコミットは、Goランタイムの `src/pkg/runtime/proc.c` ファイルにおける変数名の変更とホワイトスペースの調整に焦点を当てています。

### 変数名の変更 (`g` -> `gp`, `m` -> `mp`)

*   **対象変数**: `G` 型のローカル変数 `g` と `M` 型のローカル変数 `m`。
*   **変更理由**:
    *   **グローバル変数との衝突**: Goランタイムには、現在のゴルーチンを指すグローバル変数 `g` と、現在のOSスレッド（マシン）を指すグローバル変数 `m` が存在します。これらのグローバル変数は、ランタイムの様々な場所で暗黙的に参照されることがあります。
    *   **シャドウイングによる混乱**: 関数内で同じ名前のローカル変数 `g` や `m` が宣言されると、その関数内ではグローバル変数がローカル変数によって「シャドウ」され、アクセスできなくなります。これにより、コードを読む人がどの `g` や `m` を参照しているのかを判断するのが難しくなり、特にデバッグ時に混乱を招きます。例えば、グローバルな `g` の状態とローカルな `g` の状態を同時に確認したい場合、名前が同じだと区別がつきません。
    *   **命名規則の一貫性**: コミットメッセージにあるように、一部の関数では既に `gp` や `mp` といった命名規則が採用されていました。今回の変更は、この命名規則を `proc.c` 全体に適用することで、コードベース全体の命名規則の一貫性を高め、Goランタイムのコードスタイルを統一することを目的としています。
*   **変更の影響**: この変更は純粋なリファクタリングであり、コードのセマンティクス（動作）には一切影響を与えません。コンパイル後のバイナリの動作は変更前と全く同じです。

### ホワイトスペースの調整

*   **内容**: コード内のインデント、改行、スペースなどのホワイトスペースに関する調整。
*   **目的**: コードのフォーマットを改善し、可読性を向上させるため。Goプロジェクトでは `gofmt` などのツールによってコードフォーマットが厳密に管理されていますが、ランタイムのCコード部分では手動での調整が必要な場合もあります。
*   **影響**: 変数名のリネームと同様に、コードのセマンティクスには影響を与えません。

### 将来の変更への準備

コミットメッセージの「In preparation to bigger changes.」という記述は非常に重要です。Goランタイムは継続的に進化しており、新しい機能の追加やパフォーマンスの最適化が頻繁に行われます。このような大規模な変更を行う前に、コードベースを整理し、可読性と保守性を高めるためのリファクタリングは一般的なプラクティスです。

このリファクタリングは、GoランタイムのG-M-Pスケジューリングモデルの核心部分である `proc.c` に手を入れるものであり、将来的にスケジューラの挙動変更、新しい同期プリミティブの導入、またはメモリ管理の改善など、より複雑な変更が行われる可能性を示唆しています。クリーンな変数名は、これらの複雑な変更を導入する際のバグのリスクを減らし、開発者がコードをより迅速に理解し、変更を安全に適用できるようにするための基盤となります。

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

`src/pkg/runtime/proc.c` ファイル全体で、`G *g` と `M *m` というローカル変数の宣言と使用箇所が、それぞれ `G *gp` と `M *mp` に変更されています。

例:

**変更前:**
```c
void
runtime·goroutineheader(G *g)
{
    int8 *status;

    switch(g->status) {
    // ...
    runtime·printf("goroutine %d [%s]:\n", g->goid, status);
}

変更後:

void
runtime·goroutineheader(G *gp)
{
    int8 *status;

    switch(gp->status) {
    // ...
    runtime·printf("goroutine %d [%s]:\n", gp->goid, status);
}

同様に、M 型のローカル変数 m も mp に変更されています。

変更前:

static void
mcommoninit(M *m)
{
    m->id = runtime·sched.mcount++;
    // ...
    runtime·atomicstorep(&runtime·allm, m);
}

変更後:

static void
mcommoninit(M *mp)
{
    mp->id = runtime·sched.mcount++;
    // ...
    runtime·atomicstorep(&runtime·allm, mp);
}

コアとなるコードの解説

この変更の意義は、コードのセマンティクスを変えることなく、可読性と保守性を大幅に向上させる点にあります。

命名規則の明確化:
- Goランタイムの内部では、g と m という名前が、それぞれ「現在の実行中のゴルーチン」と「現在の実行中のOSスレッド」を指すグローバル変数として頻繁に使用されます。
- 関数内で同じ名前のローカル変数 g や m が宣言されると、そのローカルスコープ内ではグローバル変数が「シャドウ」され、アクセスできなくなります。これにより、コードを読む人が、その g や m がグローバルな現在のゴルーチン/マシンを指しているのか、それとも関数に渡された特定のゴルーチン/マシンを指しているのかを区別するのが困難になります。
- gp（goroutine pointer）と mp（machine pointer）という命名規則を採用することで、これらの変数がポインタであり、かつローカルなスコープで特定のゴルーチンやマシンを指していることが一目で明確になります。これにより、グローバルな g や m との混同が避けられ、コードの意図がより明確になります。
デバッグの容易性:
- シャドウイングが発生している場合、デバッガで g や m の値を検査しようとすると、ローカル変数の方の値しか見ることができません。グローバルな g や m の状態を確認するには、別の手段を講じる必要がありました。
- gp や mp という異なる名前を使用することで、デバッグ時にローカルなゴルーチン/マシンとグローバルなゴルーチン/マシンを明確に区別して追跡することが可能になり、デバッグ作業が格段に容易になります。
将来の変更への準備:
- Goランタイムは非常に複雑なシステムであり、その進化は継続的に行われています。このコミットは、「より大きな変更に備えるための準備」と明記されています。
- コードベースがクリーンで一貫性のある命名規則に従っていることは、将来的に新しい機能を追加したり、既存のロジックを修正したりする際に、バグを導入するリスクを減らし、開発者がコードをより迅速に理解し、安全に変更を加えるための強固な基盤となります。

この変更は、Goランタイムの内部実装の品質と保守性を高めるための、地味ながらも非常に重要なステップと言えます。

参考にした情報源リンク

Go Scheduler: Go's hidden gem: https://www.ardanlabs.com/blog/2018/08/go-scheduler.html (GoスケジューラのG-M-Pモデルに関する解説)
Go's work-stealing scheduler: https://rakyll.org/go-scheduler/ (Goのスケジューラに関する別の解説)
Variable Shadowing in Go: https://yourbasic.org/golang/variable-shadowing/ (Goにおける変数シャドウイングに関する解説)
Goのソースコード (特に src/runtime/proc.go や src/runtime/runtime.go など、スケジューラ関連のファイル)
Goのドキュメント (特にランタイムに関する部分)
Goのコミット履歴とコードレビューシステム (Gerrit)
C言語のポインタと変数スコープに関する一般的な知識

comemo

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

コミット

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

元コミット内容

変更の背景

前提知識の解説

Goランタイムとスケジューラ

`proc.c` の役割

変数名のシャドウイング

技術的詳細

変数名の変更 (`g` -> `gp`, `m` -> `mp`)

ホワイトスペースの調整

将来の変更への準備

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

コアとなるコードの解説

関連リンク

参考にした情報源リンク

コアとなるコードの解説

関連リンク

参考にした情報源リンク

Keyboard shortcuts

comemo