[valarauca1]

>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 the /proc fs.

---

What OP is doing is effectively having 1 program run part of itself in 1 container, and another part outside of that container.

Go isn't a systems programming language so this level of fine grain control isn't possible. Hell its pretty difficult in a C/Rust/C++ environment.

[YZF]

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:

  handle = open_namespace("test")
  syscall(handle, "yes")

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).

[the8472]

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.

[the_mitsuhiko]

> What's an example of it not being true in Windows?

Any of the data stored in the TIB. For instance each thread can be bound to a different subsystem.

More prominently the locale is stored there.

[the_mitsuhiko]

It's not true on macOS either. Threads can have different working directories for instance.

[bboreham]

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)

[1] https://msdn.microsoft.com/en-us/library/windows/desktop/aa3...

[the_mitsuhiko]

SYS___pthread_chdir exists on mac os.