Most "active" coroutine library project?

[Grant Edwards]

On 2009-09-25, Jason Tackaberry <tack at urandom.ca> wrote:
> 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.
>
> 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,"

It's nice that I could, because I did. :)

> 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:
>
>         import kaa
>         
>         @kaa.coroutine()
>         def task(name):
>            for i in range(10):
>               print name, i
>               yield kaa.NotFinished  # kind of like a time slice
>         
>         @kaa.coroutine()
>         def fetch_google():
>            s = kaa.Socket()
>            try:
>               yield s.connect('google.com:80')

That's not comletely transparently.  The routine fetch_google()
has to know a priori that s.connect() might want to yield and
so has to invoke it with a yield statement.  Completely
transparent would be this:

             try:
                 s.connect('google.com:80')
             except:
                 print 'Connection faild'
                 return

>            yield s.write('GET / HTTP/1.1\nHost: google.com\n\n')
>            yield (yield s.read())

Again, you have to know ahead of time which functions might
yeild and which ones don't and call them differently.  That's
the "hoop".  If somewhere in the implementation of a function
you dicover a need to yield, you have to modify all the "calls"
all the way up to the top frame.

> 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
> loop.

True.  But I wouldn't call that transparent.

-- 
Grant Edwards                   grante             Yow! Can I have an IMPULSE
                                  at               ITEM instead?
                               visi.com