threading

[Frank Millman]

"Marko Rauhamaa" <marko at pacujo.net> wrote in message 
news:877g70wg8p.fsf at elektro.pacujo.net...
> Dennis Lee Bieber <wlfraed at ix.netcom.com>:
>
>> That's been my experience too... Threading works for me... My
>> attempts at so called asyncio (whatever language) have always led to
>> my having to worry about losing data if some handler takes too long to
>> return.
>>
>> To me, asyncio is closer to a polling interrupt handler, and I
>> still need a thread to handle the main processing.
>
> Yes, asynchronous processing results in complex, event-driven state
> machines that can be hard to get right. However, my experience is that
> that's the lesser evil.
>
> About a handler taking too long: you need to guard each state with a
> timer. Also, you need then to handle the belated handler after the timer
> has expired.
>

Can I ask a newbie question here?

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.

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?

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?

Thanks for any insights.

Frank Millman