[zyga]

Hey there.

In snapd (which is implemented in mostly go) we have this problem a lot. The real issue is that certain system calls fail if more than one thread exists in the calling process. One of those is setns(2), as is documented in the manual page.

What I ended up doing is to use a small C preamble that parses command line arguments, figures out where to go and uses setns before the go code even begins initializing.

This solved the particular case we were working on but in my opinion golang's opinionated approach to threading is not suitable for writing many system tools in it.

My wishlist item for golang 2.x is a build mode where threading is 100% under developer control but this seems to be at odds with the design for non-blocking IO.

[btbuilder]

Interesting. I don't have access to the code I was talking about anymore, but I'm pretty sure that I did have different threads in different mount namespaces.

Looking at the man-page briefly it looks like the restriction you are talking about applies only to user namespaces.

Interesting to know that there are even more situations to be considered.