pkg/ns README: expand on danger in ns switching in long-lived programs

[rosenhouse]

cc: @bboreham I realized there was another key point missing in the readme: that long-lived Go processes cannot switch namespaces safely, because even new goroutines may share threads with old goroutines.

Follow up to #330 and #262

[bboreham]

(which calls Unshare from inside a new goroutine)

This isn't a necessary condition for trouble. Any time the Go runtime creates a new OS thread while the namespace was changed, you can expect some other goroutine to switch to that thread some time later.

[rosenhouse]

Good point, I've re-written this section to focus on that point. That's the "checkmate" aspect of this. It is just totally outside the control of the Go programmer.

[dcbw]

@rosenhouse can you explain the issue a bit more? I'm not quite seeing how a new goroutine that's assigned to the same OS thread as a Do() can execute and do anything until that Do() has reset the netns and exited... I'm very likely missing something :)

[bboreham]

@dcbw It's not about a new goroutine assigned to the same OS thread; it's about a new OS thread created during the Do(), that is subsequently used for any goroutine. There's loads more information if you follow the links from #262

[rosenhouse]

@dcbw @bboreham I put together a rough demo of the problem here.

The key part is here: spin up some goroutines on the main thread, and observe if their namespace is as expected.

Failures are frequent but random.

[rosenhouse]

Looks like Weave this issue, again: https://www.weave.works/blog/linux-namespaces-and-go-don-t-mix

[bboreham]

@rosenhouse the ordering was: first Weave hit this issue, then Martynas found the cause, then Bryan came over here to point out it would hit CNI the same way 🙂, then Martynas wrote a blog post, then it sat in a publication queue for months.

(Bryan sat next to Martynas at the time)

[bboreham]

This PR LGTM; @dcbw are you satisfied now?

[rosenhouse]

Closing in favor of containernetworking/plugins#14