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-May/100423.html below:

[Python-Dev] PEP 3148 ready for pronouncement

[Python-Dev] PEP 3148 ready for pronouncementNick Coghlan ncoghlan at gmail.com
Thu May 27 19:08:40 CEST 2010
On 28/05/10 02:16, Antoine Pitrou wrote:
> On Fri, 28 May 2010 02:05:14 +1000
> Nick Coghlan<ncoghlan at gmail.com>  wrote:
>>
>> Executors and thread pools are not the same thing.
>>
>> I might create a thread pool for *anything*. An executor will always
>> have a specific execution model associated with it (whether it be called
>> futures, as in this case, or runnables or something else).
>
> I'm sorry, but what is the specific execution model you are talking
> about, and how is it different from what you usually do with a thread
> pool?  Why would you do something other with a thread pool than running
> tasks and (optionally) collecting their results?

Both the execution and communications models may be different. The 
components may be long-lived state machines, they may be active objects, 
they may communicate by message passing or by manipulating shared state, 
who knows. Executors are designed around a model of "go do this and let 
me know when you're done". A general purpose pool needs to support other 
execution models, and hence will look different (and is harder to design 
and write, since it needs to be more flexible).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
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