On 26/05/10 23:29, Brian Quinlan wrote: > On 26 May 2010, at 22:50, Antoine Pitrou wrote: >> I think I'm a bit ignorant, but how is the Executor abstraction (and >> its proposed implementations) not generic enough? You have a pool, >> submit one or several tasks, and can either repeatedly poll for >> completion or do a blocking wait. >> >> (after all, Glyph pointed out that it should be quite easy to wrap the >> resulting Futures into Deferred objects) > > Interesting. Executor.submit() return a Future, which might not be > useful in some ThreadPool fire-and-forget use cases but having them > doesn't seem harmful. > > Java does take this approach and it gives you a lot more ways to > customize the Executor thread pool i.e. the minimum number of threads > running, the maximum number, the amount of time that a thread can be > idle before it is killed, the queueing strategy to use (e.g. LIFO, FIFO, > priority). I would say it is precisely that extra configurability which separates the executor pools in the PEP implementation from more flexible general purpose pools. It's something to investigate somewhere along the line, but, as Jesse pointed out, not something we need to worry about specifically for this PEP (except as an example of another module that may eventually end up in the concurrent package) Cheers, Nick. -- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia ---------------------------------------------------------------
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