On Tue, Jun 3, 2014 at 9:09 PM, Frank Millman <fr...@chagford.com> wrote: > So why not keep a 'connection pool', and for every potentially blocking > request, grab a connection, set up a callback or a 'yield from' to wait for > the response, and unblock.
Compare against a thread pool, where each thread simply does blocking requests. With threads, you use blocking database, blocking logging, blocking I/O, etc, and everything *just happens*; with a connection pool, like this, you need to do every single one of them separately. (How many of you have ever written non-blocking error logging? Or have you written a non-blocking system with blocking calls to write to your error log? The latter is far FAR more common, but all files, even stdout/stderr, can block.) I don't see how Marko's assertion that event-driven asynchronous programming is a breath of fresh air compared with multithreading. The only way multithreading can possibly be more complicated is that preemption can occur anywhere - and that's exactly one of the big flaws in async work, if you don't do your job properly. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
