4 ms·
> Go is actually a really poor choice for the container runtime because much of the container setup cannot be done from multithreaded code[0] This was addresse
by xyzzy_plugh 6y ago
> Go is actually a really poor choice for the container runtime because much of the container setup cannot be done from multithreaded code[0]
This was addressed in 2017/2018 [0], it's no longer a poor choice.
[0]: https://github.com/golang/go/commit/2595fe7fb6f272f9204ca3ef0b0c55e66fb8d90f https://github.com/golang/go/commit/2595fe7fb6f272f9204ca3ef...
- vishvananda 6y agoWhile the particular issue of network namespaces and locking the os thread was fixed, there is still c code that must run before the go runtime starts to work around the issue that you cannot do some of the necessary nsenter calls once you have started additional threads. The c code to make runc work is encapsulated in libcontainer/nsenter[0] [0]: https://github.com/opencontainers/runc/tree/master/libcontainer/nsenter https://github.com/opencontainers/runc/tree/master/libcontai...
- BenTheElder 6y agothis seems like a pretty trivial amount of C, by comparison, and a pretty solved problem now.