Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Linux Namespaces and Go Don't Mix

weave.works

Post reply on HN
Print view View original

81–90 of 175 posts

Re: Linux Namespaces and Go Don't Mix

#81

Post by jankedeen »

steveklabnik wrote: post #77
jankedeen wrote: post #70

Earlier quoted context omitted.

No. You can call fork pretty cleanly in a pthread based program. This post is not informed criticism. There is some prep for ugly contingencies(pthread_atfork) but it usually just works. Namespace based code while doing the same is like setting your hair on fire while running through the gasoline forest..but caveat emptor is usually spelled out pretty critically in the API and docs. Oh, btw: Fuck RUST. For once and f…

> Oh, btw: Fuck RUST. For once and for all fuck this tyranny of coercion by potential IP holders. It is a shit language. ... what? I am confused as to what you're saying here.

* Coercion: large down vote/propaganda community against any negative rust idea..evidenced here.

* IP Holders, well this is speculative. I can't understand anyone who would compare Rust against C in a positive way without possibly profiting from it. Rust is painful to write, painful to learn and makes you ask yourself: Can I not write a well designed and correct program in C? Of course I can. Why Am I Learning Rust? The answer seems to be peer pressure and propaganda.

* Write the same thing in C/Rust and read it in C/Rust and tell me who isn't making sense.

Re: Linux Namespaces and Go Don't Mix

#82

Post by dozzie »

di4na wrote: post #72
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…

Just saying, but Erlang do not target that type of "System Programming" and the answer to that problem in Erlang would probably work through totally different way to do it. This namespace thing would not be a problem. This is not a problem of M:N. This is a problem of Go being badly designed. Not new.

More like reification of the very old problem from the times when we got threading API, with thread safety of functions that alter process-wide state (umask(), chdir(), sleep()), except now it's calls that alter some thread-specific thing.

Re: Linux Namespaces and Go Don't Mix

#83

Post by steveklabnik »

jankedeen wrote: post #81
steveklabnik wrote: post #77

Earlier quoted context omitted.

> Oh, btw: Fuck RUST. For once and for all fuck this tyranny of coercion by potential IP holders. It is a shit language. ... what? I am confused as to what you're saying here.

* Coercion: large down vote/propaganda community against any negative rust idea..evidenced here. * IP Holders, well this is speculative. I can't understand anyone who would compare Rust against C in a positive way without possibly profiting from it. Rust is painful to write, painful to learn and makes you ask yourself: Can I not write a well designed and correct program in C? Of course I can. Why Am I Learning Rust?…

> large down vote... community

Please report this to the Hacker News mods, if you have evidence. It's against the rules, and they check this kind of thing. Nobody should be doing it.

> IP Holders, well this is speculative.

All of Rust's stuff is MIT/Apache2 licensed. There is a trademark on the name and logo, held by Mozilla, but other than that, there's none.

Re: Linux Namespaces and Go Don't Mix

#84

Post by mappu »

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…

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.

Re: Linux Namespaces and Go Don't Mix

#85

Post by jankedeen »

cyphar wrote: post #12
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__((const…

What a clumsy, terrible, crappy workaround. Congrats.

Re: Linux Namespaces and Go Don't Mix

#86

Post by klodolph »

jankedeen wrote: post #78
klodolph wrote: post #74

Earlier quoted context omitted.

> There is some prep for ugly contingencies(pthread_atfork) but it usually just works. Actually, that's not true. Perhaps it's theoretically possible, in some cases, to make your threaded code work with fork with the appropriate pthread_atfork() handlers, but in general, it's a total mess. Thread A has a lock, thread B calls fork(), thread B tries to acquire the lock. The lock is held, but thread A is not running in…

*...it's a total mess...theoretically it's possible....speculation on standard behavior based on platform behavior...namespace(x) chosen implementation detail...functional language reference... -- Translation: Design is broken

Well, then allow me to cite the standard for you.

> If a multi-threaded process calls fork() ... the child process may only execute async-signal-safe operations until such time as one of the exec functions is called.

IEEE Std 1003.1-2008, 2016 Edition

http://pubs.opengroup.org/onlinepubs/9699919799/

I don't know about "design is broken". I personally think the fork()/exec() model is a clumsy way to create a new process, but that's a matter of taste.

Re: Linux Namespaces and Go Don't Mix

#87

Post by jankedeen »

SwellJoe wrote: post #16
ahoka wrote: post #5

Earlier quoted context omitted.

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++ m…

Better C++ than Go or Rust. Antecedents and track record counts. Young people like the new thing. Go and Rust are capitalizing on that. Learn C. Take the time..it takes a couple years and some pain to learn it and then you will be amply rewarded. These languages (go|rust) are reactive and suffice for some purposes but they really kind of suck in every other possible way.

Re: Linux Namespaces and Go Don't Mix

#88

Post by voidlogic »

scriptkiddy wrote: post #59
_ph_ wrote: post #33

Earlier quoted context omitted.

Sorry, I don't understand what you mean by "Go hijacks control flow". Could you elaborate cases, where Go did not behave as you expected? And where syntactic and semantic correct Go code did not compile?

So, keep in mind that my experience with Go is not at a professional level. Take this example: https://gobyexample.com/channel-buffering As far as my understanding is concerned, channels are a way for goroutines to pass data between one another, correct? Yet in this particular case, the channel `messages` is operating in the same manner as a generator or array. So, am I creating goroutines by passing messages to the…

>Am I implicitly creating goroutines by using channels or am I simply creating a buffer?

A channel is just a thread-safe queue. An unbuffered channel blocks until something else receives the sent value. A buffered channel allows n sends until it blocks. Using a channel will never create a new goroutine, its just a way send data. You can use a select statment to wait on sending or reciving from multiple channels or to send or get without being blocked by a full or empty channel.

In C you could put together a RW mutex, condition and a linked list or array and have the same thing pretty much.... If you want to create a goroutine you need to invoke "go X".

Out of curiosity, do you know C/C++ or Java?

Re: Linux Namespaces and Go Don't Mix

#89

Post by pencilhappen »

pcwalton wrote: post #66
m0th87 wrote: post #17

Earlier quoted context omitted.

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 withou…

It's harder for us, but I think we can get to an ergonomic solution with async/await. It's not as easy as threads (M:N vs 1:1 is a red herring as far as this is concerned), but there's no free lunch.

async/await still has the fundamental problem of composability that all the other attempts at sugaring around an event loop have (aka the "functions have colors" problem [1]). It sucks for collaboration, which is one of the most important things for modern software development.

1. http://journal.stuffwithstuff.com/2015/02/01/what-color-is-y...

Re: Linux Namespaces and Go Don't Mix

#90

Post by jankedeen »

klodolph wrote: post #86
jankedeen wrote: post #78

Earlier quoted context omitted.

*...it's a total mess...theoretically it's possible....speculation on standard behavior based on platform behavior...namespace(x) chosen implementation detail...functional language reference... -- Translation: Design is broken

Well, then allow me to cite the standard for you. > If a multi-threaded process calls fork() ... the child process may only execute async-signal-safe operations until such time as one of the exec functions is called. IEEE Std 1003.1-2008, 2016 Edition http://pubs.opengroup.org/onlinepubs/9699919799/ I don't know about "design is broken". I personally think the fork()/exec() model is a clumsy way to create a new proce…

The preferred model with fork() in a thread is to exec as quickly as possible. Otherwise pthread_atfork can be prepared given adequate design: http://pubs.opengroup.org/onlinepubs/009695399/functions/pth...

If you have work to do in the thread do these in the thread. If you must fork() then exec.

Signal safety in pthreads can be handled generally via the pthread_sigmask|queue family. The corresponding facility in processes is similarly known. Yes, the conditions you posit exist but they are the product of bad development imho.

You have provided badly designed examples and worst case scenarios while noting that you dislike the unix model for process inception. Great. Now go away. You know enough to be dangerous.

Post reply on HN