[Python-ideas] Async context managers and iterators with tulip

[Nick Coghlan]

On Sun, Dec 23, 2012 at 9:06 PM, Geert Jansen <geertj at gmail.com> wrote:
> I wonder if the greenlet idea was thrown out too early. If I
> understand the discussion correctly, the #1 disadvantage that was
> identified is that calling code does not know if called code will
> switch or not. Therefore it doesn't know whether to lock, and where.

Greenlets aren't going anywhere. The thing is that "asynchronous
programming" is used to describe both an execution model that's
limited by the number of concurrent I/O operations rather than the
number of OS level threads as well as a programming model based on
cooperative (rather than preemptive) multi-threading.

Greenlets are designed to provide the scaling benefits of I/O limited
concurrency while continuing to use a preemptive multi-threading
programming model where any operation is permitted to block the thread
of execution (implicitly switching to another thread at the lowest
layer). That's *wonderful* for getting the scaling benefits of the
execution model without needing to rewrite a program to use a
drastically different programming model.

PEP 3156, on the other hand, is about providing the cooperative
multi-threading *programming* model. Greenlets can't do that, because
they're not intended to.

However, gevent/greenlets will still benefit from the explicit
asynchronous APIs in the future, as those protocols and transports
will be usable by the *networking* side of gevent. And that's a ley
part of the aim here - reducing the duplication of effort between
gevent/Twisted/Tornado/et al by eventually allowing them to share more
of the event driven protocol stacks.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia