No implementation of map_cpus on non-Linux OSes

[jonhoo]

Currently, all other OSes revert to the old sync.RWMutex behaviour of sharing a single lock. Implementing map_cpus for other OSes in cpus_GOOS.go will fix this, and should be relatively straightforward if you have a machine running that OS.

Patches are welcome.

[jonhoo]

On BSD, I suspect something like dmesg | grep -i cpu can be used based on the example output given in this post.

[jonhoo]

For Windows (and potentially also a fallback for Linux/BSD) would be to use the affinity trick that drwmutex used previously. Example code for Windows can be seen here.

[jonhoo]

OpenBSD:

$ dmesg | grep -i cpu | grep apid | awk '{print $1" "$5}' | sort -u 
cpu0 0
cpu1 1
cpu2 2
cpu3 3

I'd need confirmation that this command indeed gives the correct results on machines with more cores and on other BSDs though.

[yonderblue]

I'm not very familiar here but is there some reason tylertreat@04af2cc doesn't work?

[jonhoo]

That has two main problems. The first is that it'll run forever if the default cpu() implementation is used (rather than cpu_amd64), since that one always returns 0, which means we'll never get NumCPUS() entries. The second is that it might take a very long time to run, especially on boxes with many cores, because there's no guarantee that the task will end up getting run on every CPU in any reasonable amount of time.

[yonderblue]

First point makes sense. For the second do you mean because of the change that cpu() returns the same cpu during the map_cpus()? Thanks!

[jonhoo]

Yes, exactly. cpu() may (will) end up returning the same value over and over and over, possibly forever. The correctness (or rather, termination) of the implementation depends entirely on the OS/Go's runtime constantly moving the task to different CPUs, but in practice schedulers tend to try to do exactly the opposite.