On Sat, 27 Jun 2015 01:10:33 +1000, Chris Angelico <rosuav@gmail.com> wrote:
The way I'm seeing it, coroutines are like cooperatively-switched threads; you don't have to worry about certain operations being interrupted (particularly low-level ones like refcount changes or list growth), but any time you hit an 'await', you have to assume a context switch. That's all very well, but I'm not sure it's that big a problem to accept that any call could context-switch; atomicity is already a concern in other cases, which is why we have principles like EAFP rather than LBYL.
Read Glyph's article, it explains why: https://glyph.twistedmatrix.com/2014/02/unyielding.html
There's clearly some benefit to being able to assume that certain operations are uninterruptible (because there's no 'await' anywhere in them), but are they truly so? Signals can already interrupt something _anywhere_:
Yes, and you could have an out of memory error anywhere in your program as well. (Don't do things in your signal handlers, set a flag.) But that doesn't change the stuff Glyph talks about (and Guido talks about) about *reasoning* about your code. I did my best to avoid using threads, and never invested the time and effort in Twisted. But I love programming with asyncio for highly concurrent applications. It fits in my brain :) --David