back

by allanrbo·6y ago·view on hn ↗
He touches upon it in the "Runtime Overhead" section, but I think when calling Go from C like this you loose a lot of the goodness of Goroutines, and any code making heavy use of Goroutines could become seriously problematic.

In native Go, Goroutines are very lightweight and cooperatively scheduled. In a CGo env I believe they each have an OS thread and a full stack. Source: https://www.cockroachlabs.com/blog/the-cost-and-complexity-o...

1 comments
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

http://man7.org/linux/man-pages/man2/unshare.2.html