They do not, the go runtime just locks the OS thread to the goroutine calling C until it comes back out. This can lead to fun deadlocks that only appear on sing

They do not, the go runtime just locks the OS thread to the goroutine calling C until it comes back out. This can lead to fun deadlocks that only appear on single-core machines (because by default GOMAXPROCS is equal to the core count). Similarly, Docker locks goroutines to the OS thread when using the unshare system call to spawn containers. These are of course later discarded. It has to be locked because any goroutine might be stopped at any (automatically inserted by the compiler) checkpoint and resumed on a different OS thread. Unsharing the network interfaces from half your OS threads is a fun way to chaos test networking in Go. https://golang.org/pkg/runtime/#LockOSThread https://golang.org/pkg/runtime/#LockOSThread http://man7.org/linux/man-pages/man2/unshare.2.html http://man7.org/linux/man-pages/man2/unshare.2.html