PEP 255: Simple Generators

[Paul Jackson]

Certainly what Guido says about there being no chance of
stackless in core Python carries serious weight here.

Let me add that in my experience there are two places that
typical single thread control is not adequate.

In one case, there are two, maybe three, pieces of naturally
looping code, each of which wants to own the outer loop, calling
the others.  Perhaps one piece of code wanting to loop on input,
a second wanting to loop on a calculation being accomplished
incrementally on the flow of data, and a third wanting to loop
on output.  Typically, all but one of them has to be recoded,
as some sort of iterator with state.  Seems like 'yield' is a
natural for that case.  Sweet, very sweet.

In the other case, of more-or-less independent control flow,
I fork a process and let them communicate, if need be, via a
pipe or socket.  Usually, I use a line oriented, ascii format
across the pipe, not some binary encoded bits.  This provides
me with a natural way to trace activity.  Transparent clarity
of communication is usually (except for lower levels of protocol
or very high usage) more important than squeezing the last byte
out of the transmitted data.

In college I studied synchronization methods via shared memory
for large numbers of threads -- even published a paper in the ACM
Journal on it.  Since then, except for once coding some low level
semaphore ops in an mp library, I've never had use for such.

But perhaps I'm dating myself.  Perhaps programmers trained
in the 1990's (well, 1980's for Carnegie-Mellon) are more
indoctrinated (yes, a biased choice of wording) in threads.

There is a (meta) parallel thread to this, running on the Linux
Kernel Mailing List (lkml) right now, where the old farts are
casting dispersions at the youngins' for wanting the Linux
scheduler to handle one to three orders of magnitude more
threads than actual cpus.

Sometimes the world gets into strange harmonics ...

-- 

                          I won't rest till it's the best ...
                          Manager, Linux Scalability
                          Paul Jackson <pj at sgi.com> 1.650.933.1373