From 2ac311b6337839449f6368c55863099ae175cb6e Mon Sep 17 00:00:00 2001
From: Andrew Gerrand
+Go 1.2 introduces a configurable limit (default 10,000) to the total number of threads +a single program may have in its address space, to avoid resource starvation +issues in some environments. +Note that goroutines are multiplexed onto threads so this limit does not directly +limit the number of goroutines, only the number that may be simultaneously blocked +in a system call. +In practice, the limit is hard to reach. +
+ +
+The new SetMaxThreads
function in the
+runtime/debug
package controls the thread count limit.
+
+Updating:
+Few functions will be affected by the limit, but if a program dies because it hits the
+limit, it could be modified to call SetMaxThreads
to set a higher count.
+Even better would be to refactor the program to need fewer threads, reducing consumption
+of kernel resources.
+
+In Go 1.2, the minimum size of the stack when a goroutine is created has been lifted from 4KB to 8KB. +Many programs were suffering performance problems with the old size, which had a tendency +to introduce expensive stack-segment switching in performance-critical sections. +The new number was determined by empirical testing. +
+ +
+At the other end, the new function SetMaxStack
+in the runtime/debug
package controls
+the maximum size of a single goroutine's stack.
+The default is 1GB on 64-bit systems and 250MB on 32-bit systems.
+Before Go 1.2, it was too easy for a runaway recursion to consume all the memory on a machine.
+
+Updating: +The increased minimum stack size may cause programs with many goroutines to use +more memory. There is no workaround, but future plans for future releases +include new stack management technology that should address the problem better. +
+-- cgit v1.2.1