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/2010-March/098455.html below:

[Python-Dev] [PEP 3148] futures - execute computations asynchronously

[Python-Dev] [PEP 3148] futures - execute computations asynchronously [Python-Dev] [PEP 3148] futures - execute computations asynchronouslyBrian Quinlan brian at sweetapp.com
Tue Mar 16 21:52:22 CET 2010
Nick Coghlan wrote:
 > You may want to consider providing global thread and process  
executors
 > in the futures module itself. Code which just wants to say "do this  
in
 > the background" without having to manage the lifecycle of its own
 > executor instance is then free to do so. I've had a lot of experience
 > with a framework that provides this and it is *very* convenient (it's
 > also a good way to avoid deadlocks due to synchronous notification  
APIs).

This seems like a reasonable idea to me.

I take it that the thread/process pool should be unlimited in size.  
Should every thread/process exit when it finishes its job or should  
there be a smarter collection strategy?

Cheers,
Brian
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