On Sat, 27 Jun 2015 01:10:33 +1000, Chris Angelico <ros...@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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
