Linux Namespaces and Go Don't Mix

Post by eternalban » Sat, Jun 03, 2017, 11:37 AM UTC

scriptkiddy wrote: post #56

geodel wrote: post #32

Earlier quoted context omitted.

> The only reason Go is as popular as it is is because of Google's marketing budget. Every programmer on Earth heard of Go within a few days of it's official release. I think Google put lot of marketing budget for Dart. But I don't see it ever comes in discussion regarding popularity or lack of it. It is fine a lot of people do not like Go but claiming its popular just because of Google seems baseless.

Well, Go is obviously not a bad language. That said, I do think that it's adoption was primarily fueled by Google's popularity. Imagine go being released by a single person or small group of people. How would people have heard about it?

Post by mrout » Sat, Jun 03, 2017, 12:20 PM UTC

klodolph wrote: post #91

jankedeen wrote: post #90

Earlier quoted context omitted.

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

If you're having problems, please reach out to someone. This is not healthy behavior.

Post by the_mitsuhiko » Sat, Jun 03, 2017, 12:30 PM UTC

YZF wrote: post #120

valarauca1 wrote: post #119

Earlier quoted context omitted.

>Go assumes that all threads are equal and therefore any Goroutine can run on any thread and threads are all equal This isn't true in Linux or Windows so I don't see why Go would make this assumption other than poor design. >The property should be accessible via a handle that can be shared amongst all threads. It literally is. The namespace information is shared with all threads in a PID group globally available in t…

What's an example of it not being true in Windows? I think it's mostly true in Linux and the situations where it isn't true are subtle and require expert knowledge in some specific areas. It's not like there's a big sticker on Linux that says threads are generally not symmetric. I get the bit of half the process being in one space and half in another. I just find it odd. Can half the process run as root and half the…

Post by pjmlp » Sat, Jun 03, 2017, 12:57 PM UTC

_ph_ wrote: post #40

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…

As far as I know, Solaris threads are actually M:N threads on the system level. M:N threads are extremely efficient. A "native" thread is a heavyweight construct - e.g. by the stack space allocation. So this puts a limit on how many threads you can spawn in a program. For many tasks, this would force you to roll out your own M:N mapping system yourself. Doing it on the language level usually yields the better results…

Post by jeremyjh » Sat, Jun 03, 2017, 1:59 PM UTC

bhawks wrote: post #135

I think the proper title is: Linux Process and Threads Don't Mix. The Linux syscall interface exposes certain functionalities that are much more easy to reason about at the process level such as namespaces, capabilities, seteuid and so on. However these syscalls all operate on the thread level (since the kernel treats threads pretty similarly to processes). Therefore in order to perform these operations safely you ne…