Linux Namespaces and Go Don't Mix • Hacker News Board

Re: Linux Namespaces and Go Don't Mix

#11

Post by holydude » Fri, Jun 02, 2017, 4:52 PM UTC

scriptkiddy wrote: post #4

SwellJoe wrote: post #2

This leads to go code being roughly as messy/clumsy as C (or whatever else) code in the sections that need concurrency and also need to change namespace. That's unfortunate, but I don't know that it really "raises a few eyebrows". I mean, what's the better alternative to Go for this work? Maybe Rust? It is, at least more controllable at a lower level...but, not as easy to pick up for people coming from a C/Python/Per…

> I mean, what's the better alternative to Go for this work? Maybe Rust? It is, at least more controllable at a lower level...but, not as easy to pick up for people coming from a C/Python/Perl/Ruby systems and ops background. You know, it's interesting. I've been programming with Python for about 6 years now. I've also picked up Javascript, SQL, bash, and PHP along the way. I'm always gaining a little bit of C knowle…

Yes but the problem with languages like Nim is lack of support and maturity. Go is more versatile and at the same time more mature than anything out there. It is a different design and it excels in what it does (considering all tradeoffs now).

Will Nim be as versatile and solid as Go in the future? Hard to predict but i would say no. You need a solid financial backing and certain amount of adoption where people actually write software that makes them money.

Re: Linux Namespaces and Go Don't Mix

#12

Post by cyphar » Fri, Jun 02, 2017, 4:52 PM UTC

SwellJoe wrote: post #2

This leads to go code being roughly as messy/clumsy as C (or whatever else) code in the sections that need concurrency and also need to change namespace. That's unfortunate, but I don't know that it really "raises a few eyebrows". I mean, what's the better alternative to Go for this work? Maybe Rust? It is, at least more controllable at a lower level...but, not as easy to pick up for people coming from a C/Python/Per…

Rust is much better for this (though I still feel some of the fork/exec interface has similar warts to Go). However, you're wrong in saying that it's "roughly as messy/clumsy" as C.

Let me tell you how runc works. runc is written in Go, and we take an OCI configuration file. Because we can't just fork and set up all of the namespaces in Go, we have a C function called nsexec which is specified as __attribute__((constructor)). This ensures that our code will execute before the Go runtime boots. The parent process writes (using netlink as the wire protocol) to a pipe that the child has open and is parsed in C. Then, the child will have to do a series of forks, unshare, setns, {open,read,write} and so on (and the final PID needs to be sent back to the original parent) in order to set up and join all of the necessary namespaces.

In C, this code would be _immensely_ easier to read, write and maintain. Just look at LXC. Personally I really wish people had just gone with Rust earlier on rather than implementing everything in Go. I've had nothing but pain from Go.

Re: Linux Namespaces and Go Don't Mix

#13

Post by vishvananda » Fri, Jun 02, 2017, 4:52 PM UTC

Author of the go netlink library here. I've run into this issue a number of times. There has been conversation in the past about adding some kind of new runtime command like LockOSThread to prevent new threads from being spawned, but it didn't gain any momentum.

Even though I am a big fan of go, I've personally built two container runtimes in other languages do to the namespace clumsiness.

Personally, I think rust is an excellent alternative for namespace utilities.

EDIT: there is more information and links in the issue in the netns library: https://github.com/vishvananda/netns/issues/17

Re: Linux Namespaces and Go Don't Mix

#14

Post by lkurusa » Fri, Jun 02, 2017, 4:59 PM UTC

scriptkiddy wrote: post #4

SwellJoe wrote: post #2

This leads to go code being roughly as messy/clumsy as C (or whatever else) code in the sections that need concurrency and also need to change namespace. That's unfortunate, but I don't know that it really "raises a few eyebrows". I mean, what's the better alternative to Go for this work? Maybe Rust? It is, at least more controllable at a lower level...but, not as easy to pick up for people coming from a C/Python/Per…

> I mean, what's the better alternative to Go for this work? Maybe Rust? It is, at least more controllable at a lower level...but, not as easy to pick up for people coming from a C/Python/Perl/Ruby systems and ops background. You know, it's interesting. I've been programming with Python for about 6 years now. I've also picked up Javascript, SQL, bash, and PHP along the way. I'm always gaining a little bit of C knowle…

> The difficulty in Go is in learning about what the compiler thinks is OK.

I think this is similar to what people think about the type system in Haskell or the borrow checker in Rust. With every higher level language comes new things to learn and obey.

Re: Linux Namespaces and Go Don't Mix

#15

Post by cyphar » Fri, Jun 02, 2017, 4:59 PM UTC

vishvananda wrote: post #13

Author of the go netlink library here. I've run into this issue a number of times. There has been conversation in the past about adding some kind of new runtime command like LockOSThread to prevent new threads from being spawned, but it didn't gain any momentum. Even though I am a big fan of go, I've personally built two container runtimes in other languages do to the namespace clumsiness. Personally, I think rust is…

I completely agree, and I've been coming up with some ideas (based on runc) to see what sort of improvements can you have if you do a full redesign in a language that isn't as painful as Go to use.

At the moment I'm incredibly busy, but later this year I might be able to start working on that too.

Re: Linux Namespaces and Go Don't Mix

#16

Post by SwellJoe » Fri, Jun 02, 2017, 5:00 PM UTC

ahoka wrote: post #5

SwellJoe wrote: post #2

This leads to go code being roughly as messy/clumsy as C (or whatever else) code in the sections that need concurrency and also need to change namespace. That's unfortunate, but I don't know that it really "raises a few eyebrows". I mean, what's the better alternative to Go for this work? Maybe Rust? It is, at least more controllable at a lower level...but, not as easy to pick up for people coming from a C/Python/Per…

Better alternative to C with the same low level control? Why not C++?

I don't know, exactly, but I know with some confidence that C++ has never had significant uptake among ops and systems people. The folks who build systems, run systems, and dip into code on occasion to make the systems run, but not as their full-time job, have never (to my knowledge) fallen in love with C++. They probably all know some C, Perl, and Python...maybe not a lick of C++ (except the "C" part).

I think C++ may just be too rich a language to be a part-time thing. I think Rust might have the same problem (though I'm finding it easier to read than C++, it doesn't seem to be afraid to require a lot of learning time from its developers). But, I'm willing to entertain other theories.

For whatever reason, Go seems to have very quickly entered that category of language that systems and ops people are comfortable with.

Re: Linux Namespaces and Go Don't Mix

#17

Post by m0th87 » Fri, Jun 02, 2017, 5:00 PM UTC

pcwalton wrote: post #3

SwellJoe wrote: post #2

This leads to go code being roughly as messy/clumsy as C (or whatever else) code in the sections that need concurrency and also need to change namespace. That's unfortunate, but I don't know that it really "raises a few eyebrows". I mean, what's the better alternative to Go for this work? Maybe Rust? It is, at least more controllable at a lower level...but, not as easy to pick up for people coming from a C/Python/Per…

No, it's a lot messier than C. In a regular C program (not using any special libraries for M:N threading) you wouldn't have to spawn an entirely separate process. This issue is one of the downsides of Go's M:N scheduling. The OS is simply not aware of what the Go runtime is doing, and as a result you get impedance mismatches like this. It "raises a few eyebrows" because M:N scheduling is unpopular outside of Go and E…

This makes sense, and I know it's why Rust abandoned green threading. But I can't help but worry that the focus on async I/O in Rust as a way of avoiding this issue is going to bring the language down a path that isn't as ergonomically pleasant as Go or Erlang's M:N threading for things like highly concurrent web services. Do you share this concern, or do you think Rust can achieve the same level of ergonomics without the impedance mismatch?

Re: Linux Namespaces and Go Don't Mix

#18

Post by vbernat » Fri, Jun 02, 2017, 5:05 PM UTC

SwellJoe wrote: post #2

This leads to go code being roughly as messy/clumsy as C (or whatever else) code in the sections that need concurrency and also need to change namespace. That's unfortunate, but I don't know that it really "raises a few eyebrows". I mean, what's the better alternative to Go for this work? Maybe Rust? It is, at least more controllable at a lower level...but, not as easy to pick up for people coming from a C/Python/Per…

In Linux, many properties are task-related and therefore the API is also task-related. Namespaces are not the only problem. See for example https://github.com/golang/go/issues/1435. The problem is Go runtime does not provide a way to exclusively lock a system thread from existing or future routines. Most other languages would work just fine (C or Python for example).

Re: Linux Namespaces and Go Don't Mix

#19

Post by rkeene2 » Fri, Jun 02, 2017, 5:08 PM UTC

tankenmate wrote: post #6

ahoka wrote: post #5

Earlier quoted context omitted.

Better alternative to C with the same low level control? Why not C++?

Because C++ is vastly more complex than either C or Go.

To go along with this, due to overloading and inheritance rules you cannot look at a small section of C++ code and determine what it does without reading up to the entire program.

Re: Linux Namespaces and Go Don't Mix

#20

Post by cyphar » Fri, Jun 02, 2017, 5:08 PM UTC

SwellJoe wrote: post #10

pcwalton wrote: post #3

Earlier quoted context omitted.

No, it's a lot messier than C. In a regular C program (not using any special libraries for M:N threading) you wouldn't have to spawn an entirely separate process. This issue is one of the downsides of Go's M:N scheduling. The OS is simply not aware of what the Go runtime is doing, and as a result you get impedance mismatches like this. It "raises a few eyebrows" because M:N scheduling is unpopular outside of Go and E…

Historically, much (I would probably argue most) C concurrency has been implemented with fork. Certainly not all, and there are many ways to handle it in C...but fork is really common, and I don't think it's considered all that big of a deal to do so. It is idiomatic (at least historically and across maybe billions of lines of C code), and not much harder to reason about than many kinds of thread implementation in C;…

> C concurrency has been implemented with fork.

Arguably it has been implemented with clone(2) which has flags.

> in fact, it's easier to reason about fork than something like POSIX threads, IMHO.

Not if you call fork() in a multi-threaded program. That ends _exceptionally_ badly (let's just say there's a reason Go doesn't expose syscall.Fork and it has to do with horrific deadlocks).

> I just didn't see the problem as being all that damning of Go.

The problem is more subtle, and it comes down to maintainability and understandably. If you ever decide to read the runc codebase, I apologise. One of the reasons the codebase is so scattered is because of these sorts of hacks where you have to work around issues in the Go runtime (because it doesn't give you enough control). In the article, whenever you read the small function you have to keep in mind that it's actually spawning a subprocess (which then means you have to think about what namespaces had the process joined and so on). Go is an okay language, but it simply wasn't designed for stuff this low-level. We would be much better served with Rust in my opinion.

> But, are you saying that to switch to a namespace in Go one must fork, whereas one wouldn't need to fork in C unless you need to switch namespace and you need concurrency

In C you don't need to fork to switch namespaces, you just call setns(...). For the PID namespace you need to fork, but that's just a quirk of the interface.

In Go, you theoretically don't need to fork either (syscall.Setns is available). However, there is no real way to safely use it. First of all, the namespace interfaces in Linux are quite fragile when it comes to multi-threaded processes, but combine that with a runtime that will switch you between OS threads at random. And while the documentation on runtime.GOMAXPROC and runtime.LockOSThread might trick you into believing it's possible to stop the Go runtime from doing a clone(CLONE_THREAD|CLONE_PARENT), you can't.