Threads are the structural and functional loci of execution on some operating systems, data stored in a box accessible to each thread makes sense when you obey the constraint that the things in that box are to be used for that thread exclusively.
Goroutines are different, they function like threads but have different structure. Structurally, they are not intended to preserve state accessible to the user. Goroutines are light, and I suspect that the idiom of goroutine local storage is incompatible to the design of the language: anonymous loci of flow control communicating through channels as conduits. If I could wish for an idiom taken from operating systems, TLS/GLS wouldn't be my first choice. I see namespaces serving a similar role on Plan9. The ability to share a namespace with the child or parent process. Namespaces include the environment and allow the caller too configure what resources a process has access to upon execution. Such an addition would also violate the unwritten rule of anonymous processes, but context is already doing that. The difference is that context is based on what is being executed (what function is called) and not where (which goroutine). Contexts are like function namespaces. They even have a map of arbitrary key-values. The exercise is to find a way to make this feel natural to the language, and apply such an approach to functions instead of processes, threads, or goroutines. -- 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. For more options, visit https://groups.google.com/d/optout.
