A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2017-September/149623.html below:

[Python-Dev] PEP 554 v3 (new interpreters module)

[Python-Dev] PEP 554 v3 (new interpreters module) [Python-Dev] PEP 554 v3 (new interpreters module)MRAB python at mrabarnett.plus.com
Sat Sep 23 10:32:58 EDT 2017
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]
More information about the Python-Dev mailing list

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4