On Tue, Aug 7, 2012 at 5:21 AM, Richard Earnshaw <rearn...@arm.com> wrote: > > Wouldn't it be more useful on Linux to check the task's affinity > settings? Then when a task is locked to a limited set of cores it won't > overload those cores with threads.
Good question. I'm not sure. This patch does not change the number of threads that the Go runtime will use, so your particular concern is not an issue. This patch changes the return value of the standard library function runtime.NumCPU. And if the number of processors is > 1, it tweaks some of the runtime code, e.g., to use a limited time spin lock (if the number of processors == 1, a spin lock is pointless, and the code moves straight to a futex). I guess that if the process is restricted to a single processor by affinity, then it might be better to be aware of that and skip the spin lock. But I'm not sure what the return value of runtime.NumCPU should be. It's documented as "NumCPU returns the number of logical CPUs on the local machine." Ian
