1
0
mirror of https://github.com/golang/go synced 2024-11-26 17:56:55 -07:00

doc/faq: tweak the wording in the new section on goroutine IDs

There were too many changes of direction. Tidy up the intro a little
for better flow, and delete some unnecessary comments.

Change-Id: Ib5d85c0992626bd3152f86a51585884d3e0cab72
Reviewed-on: https://go-review.googlesource.com/80495
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This commit is contained in:
Rob Pike 2017-11-29 16:05:01 +11:00
parent 992ce90f66
commit 21672b36eb

View File

@ -1488,15 +1488,15 @@ the goroutine later.
</p>
<p>
The usage patterns that develop when threads and goroutines are
The fundamental reason goroutines are anonymous is so that
the full Go language is available when programming concurrent code.
By contrast, 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
Here is an illustration of the difficulties.
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.
@ -1507,9 +1507,9 @@ 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
Moreover, experience with libraries such as those for graphics systems
that require all processing to occur on the "main thread"
has shown 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