threading
Marko Rauhamaa
marko at pacujo.net
Wed Apr 9 09:55:09 EDT 2014
"Frank Millman" <frank at 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
More information about the Python-list
mailing list