On Thu, Jun 2, 2022 at 9:21 AM TheDiveO <harald.albre...@gmx.net> wrote: > > On Thursday, June 2, 2022 at 5:48:18 PM UTC+2 Ian Lance Taylor wrote: >> >> Can you point to any documentation about the problem. Earlier you >> mentioned that there was something in the procfs man page. I didn't >> see it, but as the procfs man page is very large I'm sure I just >> missed it. > > > You're not the only one ... it took me years to finally really grok the > ramifications of /proc/$PID/root but then it simplified some things regarding > accessing other mount namespaces significantly and gives security people > nightmares. > > Alas, examples, as Michael Kerrisk's well-written man pages don't support > deep linking, unfortunately. On the quick I found these six examples: > > /proc/[pid]/cwd: "In a multithreaded process, the contents of this symbolic > link are not available if the main thread has already terminated (typically > by calling pthread_exit(3))." > /proc/[pid]/exe: "In a multithreaded process, the contents of this symbolic > link are not available if the main thread has already terminated (typically > by calling pthread_exit(3))." (Michael is copy and pasting here) > /proc/[pid]/fd/: "In a multithreaded process, the contents of this symbolic > link are not available if the main thread has already terminated (typically > by calling pthread_exit(3))." (me envisioning Michael starting to wear out > Ctrl-V) > (I think he forgot /proc/[pid]/fdinfo/ as one is the other's evil twin; need > to poke him in Munich some day) > /proc/[pid]/root: "In a multithreaded process, the contents of this symbolic > link are not available if the main thread has already terminated (typically > by calling pthread_exit(3))." > /proc/[pid]/task: guess what ... yes ... "In a multithreaded process, the > contents of this symbolic link are not available if the main thread has > already terminated (typically by calling pthread_exit(3))." > > While probably the vast majority of Go programs on Linux will never worry > about this, system-related tools to some extend will be affected when needing > to access the above parts of the /proc filesystem while using goroutines and > LockOSThread without unlocking in order to drop tainted threads/tasks.
Thanks for the pointers. Would you be able to open an issue about this at https://go.dev/issue? Thanks. >> If you call runtime.LockOSThread in an init function, as I mentioned >> above, then the initial goroutine will be the one that calls the main >> function. > > > Will this be guaranteed to be on my mythical "T0", the leader thread (also > termed thread group leader)? Or could this be another thread? Yes, this goroutine will be running on the initial process thread. Ian -- 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/CAOyqgcV9-kbOAA45gJ-sRWomceyvDyuVi7EJPpU3qFXBjwN7-g%40mail.gmail.com.
