[Python-Dev] PEP 554 v3 (new interpreters module)
MRAB
python at mrabarnett.plus.com
Sat Sep 23 10:32:58 EDT 2017
More information about the Python-Dev mailing list
Sat Sep 23 10:32:58 EDT 2017
- Previous message (by thread): [Python-Dev] PEP 554 v3 (new interpreters module)
- Next message (by thread): [Python-Dev] PEP 554 v3 (new interpreters module)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On 2017-09-23 10:45, Antoine Pitrou wrote: > > Hi Eric, > > On Fri, 22 Sep 2017 19:09:01 -0600 > Eric Snow <ericsnowcurrently at gmail.com> wrote: >> >> Please elaborate. I'm interested in understanding what you mean here. >> Do you have some subinterpreter-based concurrency improvements in >> mind? What aspect of CSP is the PEP following too faithfully? > > See below the discussion of blocking send()s :-) > >> As to "running_interpreters()" and "idle_interpreters()", I'm not sure >> what the benefit would be. You can compose either list manually with >> a simple comprehension: >> >> [interp for interp in interpreters.list_all() if interp.is_running()] >> [interp for interp in interpreters.list_all() if not interp.is_running()] > > There is a inherit race condition in doing that, at least if > interpreters are running in multiple threads (which I assume is going > to be the overly dominant usage model). That is why I'm proposing all > three variants. > An alternative to 3 variants would be: interpreters.list_all(running=True) interpreters.list_all(running=False) interpreters.list_all(running=None) [snip]
- Previous message (by thread): [Python-Dev] PEP 554 v3 (new interpreters module)
- Next message (by thread): [Python-Dev] PEP 554 v3 (new interpreters module)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Python-Dev mailing list