Open Stack

On 2/4/14 12:07 PM, "victor stinner" <victor.stinner at enovance.com> wrote:


>The purpose of replacing eventlet with asyncio is to get a well defined
>control flow, no more surprising task switching at random points.

I disagree with this. Eventlet and gevent yield the execution context
anytime an IO call is made or the 'sleep()' function is called explicitly.
The order in which greenthreads grain execution context is deterministic
even if not entirely obvious. There is no context switching at random.
What's more is it shouldn't matter when the context switch happens. When
writing green threaded code you just pretend you have real threads and
understand that things happen in an order other than A => B => C.

One of the great benefits of using a green thread abstraction, like
eventlet or gevent, is that it lets you write normal Python code and slap
your concurrency management over the top. It even lets us program in
familiar models by pretending like we are using threads. There are some
subtle distinctions between green threading and threading that can confuse
developers, but overall programming with green threads is plain old
python. The asyncio is a completely different model for providing the same
feature set as the green thread abstractions.

Switching our async IO management from eventlet to asyncio would not be a
trivial task. Tell me when I'm wrong, but it would require that we
completely change our programming model from typical, function-call based
programming to use generator-iterators for everything. The only way to
actually use the async IO portion of asyncio is to "yield from" a
generator-iterator that ties into some kind of SELECT poll. Granted, it's
conceptually not that different from what we're already doing but why
would we want to go through the effort of changing our programming model
to get the same thing.

Honestly, if I wanted to write a bunch of utilities that provide async
behavior by calling loop.call_later() then I would just write Node.js and
call process.nextTick().