On Sat, Aug 26, 2017 at 10:25 AM, Eric Snow <ericsnowcurren...@gmail.com> wrote:
> 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.
>
> 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.
You might be interested in these notes I wrote to motivate why we need
a chain of namespaces, and why simple "async task locals" aren't
sufficient:
https://github.com/njsmith/pep-550-notes/blob/master/dynamic-scope.ipynb
They might be a bit verbose to include directly in the PEP, but
Yury/Elvis, feel free to steal whatever if you think it'd be useful.
-n
--
Nathaniel J. Smith -- https://vorpus.org
_______________________________________________
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
