In article <53477f29$0$29993$c3e8da3$54964...@news.astraweb.com>, Steven D'Aprano <steve+comp.lang.pyt...@pearwood.info> wrote:
> I think coroutines are awesome, but like all advanced concepts, sometimes > they can be abused, and sometimes they are hard to understand not because > they are hard to understand in and of themselves, but because they are > being used to do something inherently complicated. Advanced, perhaps. But certainly not new. The first "real" computer I worked on (a pdp-11/45) had a hardware instruction which swapped execution contexts. The documentation described it as being designed to support coroutines. That's a machine which was designed in the early 1970s. Heh, Wikipedia's [[Coroutine]] article says, "The term coroutine was coined by Melvin Conway in a 1963 paper". At a high level, threads and coroutines are really very similar. They are both independent execution paths in the same process. I guess the only real difference between them is that thread switching is mediated by the operating system, so it can happen anywhere (i.e. at any instruction boundary). Coroutines scheduling is handled in user code, so you have a lot more control over when context switches happen. This makes it a lot easier to manage operations which must occur atomically. They both operate in the same process memory space, so have the potential to stomp on each others data structures. They also both have the property that there is flow of control happening which is not apparent from a top-down reading of the code (exceptions, to a certain extent, have this same problem). This is fundamentally what makes them difficult to understand. -- https://mail.python.org/mailman/listinfo/python-list