aboutsummaryrefslogtreecommitdiff
path: root/doc/go_faq.html
diff options
context:
space:
mode:
authorRob Pike <r@golang.org>2017-11-28 16:05:59 +1100
committerRob Pike <r@golang.org>2017-11-29 03:24:52 +0000
commit992ce90f662467f04dd93b3bb565bb0414f82999 (patch)
tree7c8a90bc4247243c17b5683ff0f2ca55fde254f7 /doc/go_faq.html
parenta5b759aab8b9e866c0bf2dd91ffde68b6bc6766b (diff)
downloadgo-992ce90f662467f04dd93b3bb565bb0414f82999.tar.xz
doc/faq: explain why goroutines are anonymous
Fixes #22770. Change-Id: Ief62043fb6895e215d2530d2a3bf88f7ea58c875 Reviewed-on: https://go-review.googlesource.com/80195 Reviewed-by: Ian Lance Taylor <iant@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Diffstat (limited to 'doc/go_faq.html')
-rw-r--r--doc/go_faq.html47
1 files changed, 47 insertions, 0 deletions
diff --git a/doc/go_faq.html b/doc/go_faq.html
index f8322efcd3..89ed86ee9c 100644
--- a/doc/go_faq.html
+++ b/doc/go_faq.html
@@ -1476,6 +1476,53 @@ For more detail on this topic see the talk entitled,
<a href="//blog.golang.org/2013/01/concurrency-is-not-parallelism.html">Concurrency
is not Parallelism</a>.
+<h3 id="no_goroutine_id">
+Why is there no goroutine ID?</h3>
+
+<p>
+Goroutines do not have names; they are just anonymous workers.
+They expose no unique identifier, name, or data structure to the programmer.
+Some people are surprised by this, expecting the <code>go</code>
+statement to return some item that can be used to access and control
+the goroutine later.
+</p>
+
+<p>
+The usage patterns that develop when threads and goroutines are
+named can restrict what a library using them can do.
+Goroutines
+are anonymous so the full Go language is available when programming
+concurrent code.
+</p>
+
+<p>
+For example, once one names a goroutine and constructs a model around
+it, it becomes special, and one is tempted to associate all computation
+with that goroutine, ignoring the possibility
+of using multiple, possibly shared goroutines for the processing.
+If the <code>net/http</code> package associated per-request
+state with a goroutine,
+clients would be unable to use more goroutines
+when serving a request.
+</p>
+
+<p>
+Also, experience with libraries, such as those for graphics systems,
+that require all processing to occur on the "main thread",
+shows how awkward and limiting the approach can be when
+deployed in a concurrent language.
+The very existence of a special thread or goroutine forces
+the programmer to distort the program to avoid crashes
+and other problems caused by inadvertently operating
+on the wrong thread.
+</p>
+
+<p>
+For those cases where a particular goroutine is truly special,
+the language provides features such as channels that can be
+used in flexible ways to interact with it.
+</p>
+
<h2 id="Functions_methods">Functions and Methods</h2>
<h3 id="different_method_sets">