[Python-ideas] concurrency-local namespaces

Andrew Barnert abarnert at yahoo.com
Wed Apr 22 20:50:27 CEST 2015


On Apr 22, 2015, at 11:22, Guido van Rossum <guido at python.org> wrote:
> 
>> On Wed, Apr 22, 2015 at 11:12 AM, Eric Snow <ericsnowcurrently at gmail.com> wrote:
>> On Wed, Apr 22, 2015 at 11:46 AM, Guido van Rossum <guido at python.org> wrote:
>> > Hey Nathaniel, can you bring this up in the PEP 492 thread? It sounds like
>> > it would be super great if the async with statement would (optionally?)
>> > notify the context manager of switching to a different task and back.
>> 
>> Interesting idea.  Keep in mind that decimal.localcontext() makes use
>> of thread-local namespaces.  So we may still be better off if we can
>> adapt that concept to coroutines.  If I've understood correctly,
>> Tasks.current_task() should give us what we need.  I'm just not clear
>> on a couple things.  Where does the loop comes from?  Can more than
>> one loop be running at the same time?  I probably need to go dig into
>> the asyncio docs.
> 
> Usually there's only one loop, and you get it using asyncio.get_event_loop(). A loop is tied to a thread, so that function gets the current thread's loop. You could have another loop running in another thread, but it requires an explicit choice to set that up (by default you only get a loop for the main thread).

If we had loop-local variables as well as thread-local, and loops are (if there's more than one) themselves thread-local, does that mean we could have a wrapper to get "local storage", which returns the loop-local storage if get_event_loop returns a loop, and thread-local storage otherwise, and change decimal contexts (and maybe other things?) to use that wrapper?

Or is it not as simple as that?

(As a side note, since the "block"/"macro" thread last month turned into a sort of proposal for dynamically-scoped variables before fizzling out: coroutine-chain-local-storage is the reason Scheme considered adding defvar, I think in R5. It might be worth looking into why they thought the feature was unnecessary; presumably it's because there's a better way to do the same thing, and that better way might make sense for Python as well?)

> Each loop will manages a completely distinct set of tasks (and it would require some dedication and ill will to mix up tasks between loops).
> 
> You'd probably need to either have a separate asyncio-aware context for decimal, or you'd have to add asyncio-awareness to the existing context class. Both seem reasonable options; the latter seems a bit more user-friendly since users can convert existing thread-based code to coroutines without having to worry about decimal context managers across I/O waits.
> 
> -- 
> --Guido van Rossum (python.org/~guido)
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20150422/b89b7bbb/attachment-0001.html>


More information about the Python-ideas mailing list