threading

[Frank Millman]

"Marko Rauhamaa" <marko at pacujo.net> wrote in message 
news:87lhveobeq.fsf at elektro.pacujo.net...
> "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>
>

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