threading

[Frank Millman]

"Chris Angelico" <rosuav at gmail.com> wrote in message 
news:CAPTjJmqwhb8O8vq84mMTv+-Rkc3Ff1AQDXe5cs8Y5gY02kHyNg at mail.gmail.com...
> On Wed, Apr 9, 2014 at 11:23 PM, Frank Millman <frank at chagford.com> wrote:
>
>> 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?
>
> No; a blocking request is one that waits until it has a response, and
> a non-blocking request is one that goes off and does something, and
> then comes back to you when it's done.

Does reading from disk count as blocking? Strictly speaking I would have 
thought 'yes'.

In other words, non-blocking implies that everything required to pass off 
the request to a handler and be ready to deal with the next one must already 
be in memory, and it must not rely on communicating with any outside 
resource at all. Is this correct?

>
> def blocking_database_query(id):
>    print("Finding out who employee #%d is..."%id)
>    res = db.query("select name from emp where id=12345")
>    print("Employee #%d is %s."%(id,res[0].name))
>
> def nonblocking_query(id):
>    print("Finding out who employee #%d is..."%id)
>    def nextstep(res):
>        print("Employee #%d is %s."%(id,res[0].name))
>    db.asyncquery(nextstep, "select name from emp where id=12345")
>

In this example, what is 'db.asyncquery'?

If you mean that you have a separate thread to handle database queries, and 
you use a queue or other message-passing mechanism to hand it the query and 
get the result, then I understand it. If not, can you explain in more 
detail.

If I have understood correctly, then is there any benefit at all in my going 
async? I might as well just stick with threads for the request handling as 
well as the database handling.

Frank