diff options
Diffstat (limited to 'doc/go_faq.html')
| -rw-r--r-- | doc/go_faq.html | 39 |
1 files changed, 25 insertions, 14 deletions
diff --git a/doc/go_faq.html b/doc/go_faq.html index f65dff796..b1945dda8 100644 --- a/doc/go_faq.html +++ b/doc/go_faq.html @@ -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 system thread to a different, runnable thread so they won't be blocked. 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 -in long-running system calls, they cost little more than the memory -for the stack, which is just a few kilobytes. +The result, which we call goroutines, can be very cheap: they have little +overhead beyond the memory for the stack, which is just a few kilobytes. </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. -When it isn't, the run-time allocates (and frees) extension segments automatically. -The overhead averages about three cheap instructions per function call. +When it isn't, the run-time grows (and shrinks) the memory for storing +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 -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. </p> @@ -446,7 +448,7 @@ Why are map operations not defined to be atomic?</h3> <p> After long discussion it was decided that the typical use of maps did not require -safe access from multiple threads, and in those cases where it did, the map was +safe access from multiple goroutines, and in those cases where it did, the map was probably part of some larger data structure or computation that was already synchronized. Therefore requiring that all map operations grab a mutex would slow down most programs and add safety to few. This was not an easy decision, @@ -938,9 +940,9 @@ How are libraries documented?</h3> There is a program, <code>godoc</code>, written in Go, that extracts package documentation from the source code. It can be used on the command line or on the web. An instance is running at -<a href="http://golang.org/pkg/">http://golang.org/pkg/</a>. +<a href="/pkg/">http://golang.org/pkg/</a>. In fact, <code>godoc</code> implements the full site at -<a href="http://golang.org/">http://golang.org/</a>. +<a href="/">http://golang.org/</a>. </p> <h3 id="Is_there_a_Go_programming_style_guide"> @@ -957,6 +959,14 @@ compendium of do's and don'ts that allows interpretation. All the Go code in the repository has been run through <code>gofmt</code>. </p> +<p> +The document titled +<a href="http://golang.org/s/comments">Go Code Review Comments</a> +is a collection of very short essays about details of Go idiom that are often +missed by programmers. +It is a handy reference for people doing code reviews for Go projects. +</p> + <h3 id="How_do_I_submit_patches_to_the_Go_libraries"> How do I submit patches to the Go libraries?</h3> @@ -1427,7 +1437,7 @@ each closure shares that single variable. When the closure runs, it prints the value of <code>v</code> at the time <code>fmt.Println</code> is executed, but <code>v</code> may have been modified since the goroutine was launched. To help detect this and other problems before they happen, run -<a href="http://golang.org/cmd/go/#hdr-Run_go_tool_vet_on_packages"><code>go vet</code></a>. +<a href="/cmd/go/#hdr-Run_go_tool_vet_on_packages"><code>go vet</code></a>. </p> <p> @@ -1606,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 control; it is compiled with a version of the Plan 9 C compiler that supports -segmented stacks for goroutines. -The <code>gccgo</code> compiler implements segmented -stacks on Linux only, supported by recent modifications to the gold linker. +resizable stacks for goroutines. +The <code>gccgo</code> compiler implements these on Linux only, +using a technique called segmented stacks, +supported by recent modifications to the gold linker. </p> <h3 id="Why_is_my_trivial_program_such_a_large_binary"> |