Most "active" coroutine library project?

[Arlo Belshee]

On Sep 25, 2:07 pm, Grant Edwards <inva... at invalid.invalid> wrote:
> On 2009-09-25, Jason Tackaberry <t... at urandom.ca> wrote:
>
> > And I maintain that requiring yield doesn't make it any less a
> > coroutine.
>
> > Maybe we can call this an aesthetic difference of opinion?
>
> Certainly.
>
> You've a very valid point that "transparent" can also mean
> "invisible", and stuff happening "invisibly" can be a source of
> bugs.  All the invisible stuff going on in Perl and C++ has
> always caused headaches for me.

There are some key advantages to this transparency, especially in the
case of libraries built on libraries. For example, all the networking
libraries that ship in the Python standard lib are based on the
sockets library. They assume the blocking implementation, but then add
HTTPS, cookie handling, SMTP, and all sorts of higher-level network
protocols.

I want to use non-blocking network I/O for (concurrency) performance.
I don't want to re-write an SMTP lib - my language ships with one.
However, it is not possible for someone to write a non-blocking socket
that is a drop-in replacement for the blocking one in the std lib.
Thus, it is not possible for me to use _any_ of the well-written
libraries that are already part of Python's standard library. They
don't have yields sprinkled throughout, so they can't work with a non-
blocking, co-routine implemented socket. And they certainly aren't
written against the non-blocking I/O APIs.

Thus, the efforts by lots of people to write entire network libraries
that, basically, re-implement the Python standard library, but change
the implementation of 7 methods (bind, listen, accept, connect, send,
recv, close). They end up having to duplicate tens of thousands of
LoC, just to change 7 methods.

That's where transparency would be nice - to enable that separation of
concerns.