[issue17140] Provide a more obvious public ThreadPool API

Changes by Sebastian Rodriguez : -- nosy: +srodriguez ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://m

[issue17140] Provide a more obvious public ThreadPool API

Richard Oudkerk added the comment: I understand that a thread pool (in the general sense) might be used to amortise the cost. But I think you would probably have to write this from scratch rather than use the ThreadPool API. The ThreadPool API does not really expose anything that the ThreadPo

[issue17140] Provide a more obvious public ThreadPool API

Nick Coghlan added the comment: Actors are just as vulnerable to the "new threads/processes are expensive" issue as anything else, and by using a dynamic pool appropriately you can amortise those costs across multiple instances. The point is to expose a less opinionated threading model in a mo

[issue17140] Provide a more obvious public ThreadPool API

Richard Oudkerk added the comment: > It's a very different architecture from that assumed by futures, > so you need to drop down to the pool layer rather than using the > executor model. AIUI an ThreadPoolExecutor object (which must be explicitly created) represents a thread/process pool, and

[issue17140] Provide a more obvious public ThreadPool API

Nick Coghlan added the comment: No, I mean implementing communicating sequential processes with independent state machines passing messages to each other. There aren't necessarily any fixed request/reply pairs. Each actor has a "mailbox", which is a queue that you dump its messages into. If yo

[issue17140] Provide a more obvious public ThreadPool API

Richard Oudkerk added the comment: As far as I can see they are mostly equivalent. For instance, ApplyResult (the type returned by Pool.apply_async()) is virtually the same as a Future. When you say "explicit message passing", do you mean creating a queue and making the worker tasks put resul

[issue17140] Provide a more obvious public ThreadPool API

Nick Coghlan added the comment: Future are explicitly about kicking off a concurrent call and waiting for a reply. They're great for master/slave and client/server models, but not particularly good for actors and other forms of peer-to-peer message passing. For the latter, explicit pools and m

[issue17140] Provide a more obvious public ThreadPool API

Richard Oudkerk added the comment: I don't understand what you mean by "explicit message passing" and "call-and-response model". -- ___ Python tracker ___ ___

[issue17140] Provide a more obvious public ThreadPool API

Nick Coghlan added the comment: Thread Pools can be handy when you want to do explicit message passing, rather than the call-and-response model favoured by the futures module. -- ___ Python tracker ___

[issue17140] Provide a more obvious public ThreadPool API

Richard Oudkerk added the comment: Given that the change could only be made to 3.4, and we already have concurrent.futures.ThreadPoolExecutor, I am not sure there is much point to such a change now. -- nosy: +sbt ___ Python tracker

[issue17140] Provide a more obvious public ThreadPool API

Changes by Tillmann Karras : -- nosy: +Tilka ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python

[issue17140] Provide a more obvious public ThreadPool API

New submission from Nick Coghlan: The multiprocessing module currently provides the "multiprocessing.dummy.ThreadPool" API that exposes the same API as the public multiprocessing.Pool, but is implemented with threads rather than processes. (This is sort of documented - it's existence is implie