threading

[Roy Smith]

In article <53477f29$0$29993$c3e8da3$5496439d at news.astraweb.com>,
 Steven D'Aprano <steve+comp.lang.python at 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.