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 it is used to send tasks to the workers in the pool. And if you want to ignore the future object returned by submit(), then you can. How is that any different from a ThreadPool object? And if you are impementing actors on top of a thread pool then isn't there a limit on the number "active" actors there can be at any one time, potentially creating deadlocks because all workers are waiting for messages from an actor which cannot run yet. (I am probably misunderstanding what you mean.) To me, the obvious way to implement actors would be to create one thread/process for each actor. In Python 3.4 one could use the tulip equivalents instead for better scalability. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue17140> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
