Even after some research I couldn't find -- or stupidly missed -- what happens in this case; I suspect this to "somehow" be the underlaying cause of some of my applications ending up with their main OS-level thread sitting in the wrong network namespace albeit I made sure to ditch all OS-level threads after being "tainted" by switching namespaces. The problem seems to go away when I immediately lock the main Go routines OS-level thread before doing anything else, but I'm unsure if that is just by chance or a correct cure?
So that's what I'm doing right now: - a goroutine *G* (which *isn't the main Goroutine,* the one with ID 1) is scheduled by some arcane Gopher scheduling deity of bad luck onto the *main OS-level thread T0* that is *also representing (at least on Linux) the process* as such. If I remember correctly, this is also termed the "task leader", but I slightly disgress. - now that goroutine *G* on thread *T0* calls *runtime.LockOSThread()* and say, switches one of its Linux kernel namespaces, maybe its network namespace. - after doing some work, *G locked to T0* now simply terminates. What happens to T0, the initial/leader thread representing the whole program process? My (albeit limited) understand so far for *T OS-level threads that aren't T0* is that when a *G* terminates while still runtime.LockOSThread'ed, this correctly throws away *T* as to avoid reusing it on a different unsuspecting G' and with the wrong namespaces set. But what about *T0*? Wouldn't throwing away T0 terminate the whole program ... which doesn't seem to be the case? Or am I mistaken here? -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/f231ab23-68fd-4fb4-b2bb-76391ce737a5n%40googlegroups.com.
