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