I'm personally reasonably happy with Context as-is. Bit if you are looking for a better solution, I completly agree with "as.utf8": the solution won't be found in TLS/GLS (goroutine local storage) but in some other contextual/namespace/arena type thing that is larger then a single goroutine, is still cooperative, and can expose properties that allow transporting it over the network as Context allows today.
On Mon, Aug 7, 2017 at 10:46 PM <as.u...@gmail.com> wrote: > 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 a topic in the > Google Groups "golang-nuts" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/golang-nuts/eEDlXAVW9vU/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > golang-nuts+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- 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.
