From dc3b4932d887eb9a105b7f6f084d0fd930ba6fc3 Mon Sep 17 00:00:00 2001
From: Rob Pike <r@golang.org>
Date: Sun, 15 Nov 2009 13:09:43 -0800
Subject: [PATCH] add a paragraph about GOMAXPROCS

R=rsc
CC=golang-dev
https://golang.org/cl/154153
---
 doc/effective_go.html | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/doc/effective_go.html b/doc/effective_go.html
index 2c82ac91b7..cd6ac53602 100644
--- a/doc/effective_go.html
+++ b/doc/effective_go.html
@@ -2233,6 +2233,22 @@ func (v Vector) DoAll(u Vector) {
 
 </pre>
 
+<p>
+The current implementation of <code>gc</code> (<code>6g</code>, etc.)
+will not parallelize this code by default.
+It dedicates only a single core to user-level processing.  An
+arbitrary number of goroutines can be blocked in system calls, but
+by default only one can be executing user-level code at any time.
+It should be smarter and one day it will be smarter, but until it
+is if you want CPU parallelism you must tell the run-time
+how many goroutines you want executing code simultaneously.  There
+are two related ways to do this.  Either run your job with environment
+variable <code>GOMAXPROCS</code> set to the number of cores to use
+(default 1); or import the <code>runtime</code> package and call
+<code>runtime.GOMAXPROCS(NCPU)</code>.
+Again, this requirement is expected to be retired as the scheduling and run-time improve.
+</p>
+
 <h3 id="leaky_buffer">A leaky buffer</h3>
 
 <p>