No, no it doesn't. CGo is slow as balls to call into and return from.
Types can't fully be shared.
It's interacted with via comments.
You can't use cgo to control the threading of the Go runtime itself, which is the real problem here.
The behavior you want is to be able to call linux syscalls that operate on threads and not be utterly fucked.
That behavior cannot be accomplished with go nor go+cgo easily.
> You can't use cgo to control the threading of the Go runtime itself, which is the real problem here.
Go is deliberately opinionated about threading of the runtime. I think it's unlikely Go will offer much more control over these internals (beyond GOMAXPROCS), given the philosophy around e.g. GC tuning.
Cgo is a beefed-up runtime.LockOSThread() that could be used to avoid having the author resort to a helper process.
> CGo is slow as balls to call into and return from.
They're slower than Go function calls, but they still take only nanoseconds. This is negligible on the authors' scale of "launching an entire container".
For their case of "it is not possible to guarantee that a new OS process ... will run in a given namespace", you're not even returning from Cgo after exec.
> It's interacted with via comments.
Do you use build tags? Or go:generate? Like it or not, it's idiomatic.
I'm with you on the types, though! `go tool cgo -godefs` helps, but it would be great to see improvements especially in the reverse case of exporting Go buildmode=c-shared for C consumption. Still, a little marshaling seems tidier than a whole helper process.
Yeah, you're correct. Though it doesn't change that it's a deceptively named variable -- you have to read the runtime docs carefully to realise that it only refers to the number of threads concurrently executing Go code.
No, no it doesn't. CGo is slow as balls to call into and return from.
Types can't fully be shared.
It's interacted with via comments.
You can't use cgo to control the threading of the Go runtime itself, which is the real problem here.
The behavior you want is to be able to call linux syscalls that operate on threads and not be utterly fucked. That behavior cannot be accomplished with go nor go+cgo easily.
Threads in cgo are also kinda fucked.