Most "active" coroutine library project?
tack at urandom.ca
Fri Sep 25 20:07:32 CEST 2009
On Fri, 2009-09-25 at 15:42 +0000, Grant Edwards wrote:
> You can't call a function that yields control back to the other
> coroutine(s). By jumping through some hoops you can get the
> same effect, but it's not very intuitive and it sort of "feels
> wrong" that the main routine has to know ahead of time when
> calling a function whether that function might need to yield or
Not directly, but you can simulate this, or at least some pseudo form of
it which is useful in practice. I suppose you could call this "jumping
through some hoops," but from the point of view of the coroutine, it can
be done completely transparently, managed by the coroutine scheduler.
In kaa, which I mentioned earlier, this might look like:
for i in range(10):
print name, i
yield kaa.NotFinished # kind of like a time slice
s = kaa.Socket()
print 'Connection failed'
yield s.write('GET / HTTP/1.1\nHost: google.com\n\n')
yield (yield s.read())
page = yield fetch_google()
print 'Fetched %d bytes' % len(page)
The two task() coroutines spawned by orchestrate() continue to "run in
the background" while any of the yields in fetch_google() are pending
(waiting on some network resource).
It's true that the yields in fetch_google() aren't yielding control
_directly_ to one of the task() coroutines, but it _is_ doing so
indirectly, via the coroutine scheduler, which runs inside the main
More information about the Python-list