[Python-Dev] microthreading vs. async io

Phillip J. Eby pje at telecommunity.com
Thu Feb 15 17:32:03 CET 2007


At 11:00 PM 2/14/2007 -0600, dustin at v.igoro.us wrote:
>Instead, I would like to concentrate on producing a small, clean,
>consistent, generator-based microthreading library.  I've seen several
>such libraries (including the one in PEP 342, which is fairly skeletal),
>and they all work *almost* the same way, but differ in, for example, the
>kinds of values that can be yielded, their handling of nested calls, and
>the names for the various "special" values one can yield.

Which is one reason that any "standard" coroutine library would need to be 
extensible with respect to the handling of yielded values, e.g. by using a 
generic function to implement the yielding.  See the 'yield_to' function in 
the example I posted.

Actually, the example I posted would work fine as a microthreads core by 
adding a thread-local variable that points to some kind of "scheduler" to 
replace the Twisted scheduling functions I used.  It would need to be a 
variable, because applications would have to be able to replace it, e.g. 
with the Twisted reactor.

In other words, the code I posted isn't really depending on Twisted for 
anything but reactor.callLater() and the corresponding .isActive() and 
.cancel() methods of the objects it returns.  If you add a default 
implementation of those features that can be replaced with the Twisted 
reactor, and dropped the code that deals with Deferreds and TimeoutErrors, 
you'd have a nice standalone library.



More information about the Python-Dev mailing list