[mappu]

You can keep using Go. Its behaviour here is actually usually what you want.

To avoid the authors' issue, you can write some functions in C. CGo has a very high level of integration (you can mix languages in the same source file) and would be quite simple for the case of a setns/execve wrapper.

[TheDong]

> CGo has a very high level of integration

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.

[mappu]

> 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.

[cyphar]

> I think it's unlikely Go will offer much more control over these internals (beyond GOMAXPROCS)

GOMAXPROCS is actually a lie. If you set it to 1, the runtime will still create threads.

[mappu]

> GOMAXPROCS is actually a lie. If you set it to 1, the runtime will still create threads.

It's not a lie. The variable is GOMAXPROCS, not GOMAXTHREADS. "procs" is specific jargon of the G:M:P scheduler design.

[cyphar]

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.