From 992ce90f662467f04dd93b3bb565bb0414f82999 Mon Sep 17 00:00:00 2001 From: Rob Pike <r@golang.org> Date: Tue, 28 Nov 2017 16:05:59 +1100 Subject: [PATCH] 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> --- doc/go_faq.html | 47 +++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 47 insertions(+) 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"> -- 2.30.9