"Frank Millman" <fr...@chagford.com>: > I understand that, if one uses threading, each thread *can* block > without affecting other threads, whereas if one uses the async > approach, a request handler must *not* block, otherwise it will hold > up the entire process and not allow other requests to be handled.
Yes. > How does one distinguish betwen 'blocking' and 'non-blocking'? Is it > either/or, or is it some arbitrary timeout - if a handler returns within > that time it is non-blocking, but if it exceeds it it is blocking? Old-school I/O primitives are blocking by default. Nonblocking I/O is enabled with the setblocking() method. In the new asyncio package, I/O is nonblocking by default (I'm sure, but didn't verify). > In my environment, most requests involve a database lookup. I > endeavour to ensure that a response is returned quickly (however one > defines quickly) but I cannot guarantee it if the database server is > under stress. Is this a good candidate for async, or not? Database libraries are notoriously bad for nonblocking I/O. It's nothing fundamental; it's only that the library writers couldn't appreciate the worth of async communication. For that, asyncio provides special support: <URL: https://docs.python.org/3.4/library/asyncio-dev.html# handle-blocking-functions-correctly> Marko -- https://mail.python.org/mailman/listinfo/python-list
