qbit/go
1
0
Fork 0
mirror of https://github.com/golang/go synced 2024-11-23 05:20:11 -07:00
Code Releases Activity

doc/go_faq.html: update description of stack management

Browse Source 
They aren't segmented any more, at least with gc.
Also improve the comparison of goroutines and threads.
Fixes #7373.

LGTM=iant
R=iant
CC=golang-codereviews
https://golang.org/cl/77950044
This commit is contained in:
Rob Pike 2014-03-21 13:59:30 +11:00
parent 0c8415699e
commit 287967f74c
1 changed files with 13 additions and 10 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

23
doc/go_faq.html
View File

@ -426,18 +426,20 @@ When a coroutine blocks, such as by calling a blocking system call,
the run-time automatically moves other coroutines on the same operating the run-time automatically moves other coroutines on the same operating
system thread to a different, runnable thread so they won't be blocked. system thread to a different, runnable thread so they won't be blocked.
The programmer sees none of this, which is the point. The programmer sees none of this, which is the point.
The result, which we call goroutines, can be very cheap: unless they spend a lot of time The result, which we call goroutines, can be very cheap: they have little
in long-running system calls, they cost little more than the memory overhead beyond the memory for the stack, which is just a few kilobytes.
for the stack, which is just a few kilobytes.
</p> </p>
<p> <p>
To make the stacks small, Go's run-time uses segmented stacks. A newly To make the stacks small, Go's run-time uses resizable, bounded stacks. A newly
minted goroutine is given a few kilobytes, which is almost always enough. minted goroutine is given a few kilobytes, which is almost always enough.
When it isn't, the run-time allocates (and frees) extension segments automatically. When it isn't, the run-time grows (and shrinks) the memory for storing
The overhead averages about three cheap instructions per function call. the stack automatically, allowing many goroutines to live in a modest
amount of memory.
The CPU overhead averages about three cheap instructions per function call.
It is practical to create hundreds of thousands of goroutines in the same It is practical to create hundreds of thousands of goroutines in the same
address space. If goroutines were just threads, system resources would address space.
If goroutines were just threads, system resources would
run out at a much smaller number. run out at a much smaller number.
</p> </p>
@ -1614,9 +1616,10 @@ it now. <code>Gccgo</code>'s run-time support uses <code>glibc</code>.
<code>Gc</code> uses a custom library to keep the footprint under <code>Gc</code> uses a custom library to keep the footprint under
control; it is control; it is
compiled with a version of the Plan 9 C compiler that supports compiled with a version of the Plan 9 C compiler that supports
segmented stacks for goroutines. resizable stacks for goroutines.
The <code>gccgo</code> compiler implements segmented The <code>gccgo</code> compiler implements these on Linux only,
stacks on Linux only, supported by recent modifications to the gold linker. using a technique called segmented stacks,
supported by recent modifications to the gold linker.
</p> </p>
<h3 id="Why_is_my_trivial_program_such_a_large_binary"> <h3 id="Why_is_my_trivial_program_such_a_large_binary">