[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