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.
I'm old(ish), have worked professionally with C, and I think I have to disagree with you. Certainly, learn some C; it's the language on which all of our platforms are currently built.
But, building new things in C? Nah. I don't see any reason for that. Since C was designed, we've ("we" as in our industry, not specifically me and you) learned a lot and our systems have grown massively in all dimensions. It would be optimistic to assume we don't need different tools 40+ years on.
I never said it was a nice hack. Personally I think this would be infinitely better in C or Rust.
Oh, and I haven't even mentioned the absolute shitfest that is the cgroup namespace and how you have to set up cgroups before you unshare it because its behaviour changes based on what cgroups you were in when you unshared it.
It's a common practice in C to use thread pools for concurrency and queue tasks for those thread pools (e.g. libuv). I work on a C++ code base that mainly uses Goroutine like green threads. If you use a scheme like that you're kind of in the same position (at least with respect to anything running on that pool). It's true that it's easy to "escape" and manage your threads explicitly but unless you know exactly what you're doing you could run into similar issues.
I really don't think this is a language design issue but clearly if you want absolute control you can't get that with the Go run-time.
Because this isn't really a language issue. It's an OS issue. Go assumes that all threads are equal and therefore any Goroutine can run on any thread and threads are all equal. Linux got late to the thread party and its threads are kind of like processes that haven't decided if they want to be processes or threads.
It's true the Go runtime could give users more control over goroutine and thread scheduling but that would kind of defeat the purpose of not needing to know about it and having Goroutines as the only flexible unit of concurrency.
I think the kludge here is on the Linux side. Having some magic properties bestowed upon threads doesn't make sense. The property should be accessible via a handle that can be shared amongst all threads.
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 process run as another user? Maybe yes? Can a file be open in half the process and not open in the other?
At any rate, I think it's not black and white. Green threads do make sense in general and introducing different thread types and more granular control makes things more complicated.
I think you're missing my point about APIs and handles:
if handle can be used across threads then this sequence will run correctly regardless of what thread is executing it, it doesn't rely on anything bestowed on a thread.
(EDIT: thread local storage I guess is an example of asymmetry between threads but it's intentional/clear asymmetry designed for specific purposes and something you don't need to access in Go e.g. because you don't use threads directly).
Maybe your assumption of symmetry is just backwards? If you look at the clone syscall then threads are more akin to processes that just happen to share virtual memory and some other things such as IO priorities, file desciptor tables, cgroups, .... Many of those things can be shared individually. In other words they are considered orthogonal features that, when taken together, happen to function as threads.
I'd be interested to know how to do that. Go's Chdir() calls SYS_CHDIR on Darwin, and Posix requires that chdir affects the whole process.
In Linux you can unset CLONE_FS when creating a thread, but the Go runtime does not do this.
I note the Windows docs[1] say "Multithreaded applications and shared library code should not use the SetCurrentDirectory function" (which Go's Chdir() calls)
It's possible they didn't know different Linux threads can be in different namespaces, it's not exactly something everyone knows. Namespaces in Linux aren't that new (15 years or so). It's possible they knew but decided this wasn't an important enough use case to warrant language features.
I've never needed to have half my process in one namespace and half in another. It's a niche application. Green threads/goroutines is something I use extensively and I wouldn't give it up for the ability to have half my process in another namespace. There's probably some middle ground there in giving Go users more control over which thread pools run which goroutines...
Someone should file a Go bug and see what the response is...
> Someone should file a Go bug and see what the response is...
From memory, several people working on Docker have done so over the years. It's still a problem because the only "real" solutions are:
1. Do what glibc does and implement nptl(7) (effectively a way to make Linux threads look like POSIX threads by synchronising certain operations on all threads). This would require making first-class library APIs for Linux features (outside of the wild-west that is syscall).
2. Give programs far more control over threading, which would require making runtime.LockOSThread and GOMAXPROCS actually do what their documentation says. However, that would restrict their ability to be opinionated about threading (and would almost certainly cause deadlocks in some programs) so I understand why they don't want to do this either.
It's not that nobody is interested anymore. It is that the onus is on regular citizens to protect themselves. Once you have an understanding of the magnitude of the privacy problem and see what you would have to do to protect yourself you tend to tip your hat to the empowered opposition and industry partners and realize,in the venerable argot of our time: you lost the game.
War.
These are the men who are missing out on the great civilized purge of useless, direction-less, education-less, baby dads.
Not practicable anymore. There is no great enemy, the military services don't want these problem children.
Our direction is unsustainable but nobody likes this particular historical necessity.
External monitoring from AWS or a colo.
Simple icmp checks and tcp connects + possible up to
app layer checks allowed from these failsafes. Obfuscate
as needed.
I think you are a really good programmer by the time you use Tcl again: as a complementary language for test automation, or to integrate it in your software as DSL...
First you use it because it is simple to learn. Then you outgrow it and blame its weaknesses. Then you remember its strengths from a different perspective and pick it up again :)
