This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author sbt
Recipients Tilka, ncoghlan, sbt
Date 2013-05-21.14:16:28
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
In-reply-to <>
> 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.
Date User Action Args
2013-05-21 14:16:28sbtsetrecipients: + sbt, ncoghlan, Tilka
2013-05-21 14:16:28sbtlinkissue17140 messages
2013-05-21 14:16:28sbtcreate