"Marko Rauhamaa" <ma...@pacujo.net> wrote in message news:87lhveobeq....@elektro.pacujo.net... > "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> >
Thanks for the reply, Marko. I did have a look at the link you provided, but at the moment my brain is 'blocking' on this, so I will need to read it a few times to get back into 'async' mode. As I asked Chris, (so you don't have to respond if he already has), I am finding difficulty in understanding the benefit of going async in my case. If most requests require a blocking handler, it seems that I might as well stick with each request being handled by a thread, independent of all other threads. Frank -- https://mail.python.org/mailman/listinfo/python-list
