Hi Eric, On Sat, Aug 26, 2017 at 1:25 PM, Eric Snow <ericsnowcurren...@gmail.com> wrote: > Thanks for the update. Comments in-line below. > > -eric > > On Fri, Aug 25, 2017 at 4:32 PM, Yury Selivanov <yselivanov...@gmail.com> > wrote: >> [snip] >> >> This PEP adds a new generic mechanism of ensuring consistent access >> to non-local state in the context of out-of-order execution, such >> as in Python generators and coroutines. >> >> Thread-local storage, such as ``threading.local()``, is inadequate for >> programs that execute concurrently in the same OS thread. This PEP >> proposes a solution to this problem. > >> [snip] >> >> In regular, single-threaded code that doesn't involve generators or >> coroutines, context variables behave like globals:: >> >> [snip] >> >> In multithreaded code, context variables behave like thread locals:: >> >> [snip] >> >> In generators, changes to context variables are local and are not >> visible to the caller, but are visible to the code called by the >> generator. Once set in the generator, the context variable is >> guaranteed not to change between iterations:: > > With threads we have a directed graph of execution, rooted at the root > thread, branching with each new thread and merging with each .join(). > Each thread gets its own copy of each threading.local, regardless of > the relationship between branches (threads) in the execution graph. > > With async (and generators) we also have a directed graph of > execution, rooted in the calling thread, branching with each new async > call. Currently there is no equivalent to threading.local for the > async execution graph. This proposal involves adding such an > equivalent.
Correct. > > However, the proposed solution isn''t quite equivalent, right? It > adds a concept of lookup on the chain of namespaces, traversing up the > execution graph back to the root. threading.local does not do this. > Furthermore, you can have more than one threading.local per thread. > From what I read in the PEP, each node in the execution graph has (at > most) one Execution Context. > > The PEP doesn't really say much about these differences from > threadlocals, including a rationale. FWIW, I think such a COW > mechanism could be useful. However, it does add complexity to the > feature. So a clear explanation in the PEP of why it's worth it would > be valuable. Currently, the PEP covers the proposed mechanism in-depth, explaining why every detail of the spec is the way it is. But I think it'd be valuable to highlight differences from theading.local() in a separate section. We'll think about adding one. Yury _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
