"Marko Rauhamaa" <ma...@pacujo.net> wrote in message news:877g70wg8p....@elektro.pacujo.net... > Dennis Lee Bieber <wlfr...@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 -- https://mail.python.org/mailman/listinfo/python-list
