此文翻譯自 Mark McLoughlin 的 博客
Async I/O and Python
原文：http://blogs.gnome.org/markmc/2013/06/04/async-io-and-python
Eventlet
Ok, so how about eventlet? Presumably eventlet makes it a lot easier to implement non-blocking I/O than the above example? Here’s what it looks like with eventlet:
使用eventlet可以更容易實現非阻塞式IO：
from eventlet.green import socket
sock = socket.socket()
sock.connect(('localhost', 1234))
sock.send('foo\n' * 10 * 1024 * 1024)Yes, that does look very like the first example. What has happened here is that by creating the socket using eventlet.green.socket.socket() we have put the socket into non-blocking mode and when the write to the socket blocks, eventlet will schedule any other work that might be pending. Hitting Ctrl-C while this
is running is actually pretty instructive:
使用eventlet.green.socket.socket()啓用非阻塞模式向阻塞的sokcet寫數據時，eventlet可以安排其他工作運行， 按Ctrl+C更有啓發式地運行。
$> python test-eventlet-write.py
^CTraceback (most recent call last):
File "test-eventlet-write.py", line 6, in
sock.send('foo\n' * 10 * 1024 * 1024)
File ".../eventlet/greenio.py", line 289, in send
timeout_exc=socket.timeout("timed out"))
File ".../eventlet/hubs/__init__.py", line 121, in trampoline
return hub.switch()
File ".../eventlet/hubs/hub.py", line 187, in switch
return self.greenlet.switch()
File ".../eventlet/hubs/hub.py", line 236, in run
self.wait(sleep_time)
File ".../eventlet/hubs/poll.py", line 84, in wait
presult = self.do_poll(seconds)
File ".../eventlet/hubs/epolls.py", line 61, in do_poll
return self.poll.poll(seconds)
KeyboardInterruptYes, indeed, there’s a whole lot going on behind that innocuous looking send() call. You see mention of a ‘hub’ which is eventlet’s name for an event loop. You also see this trampoline() call which means “put the current code to sleep until the socket is writable”. And, there at the very end, we’re still sleeping in a call to poll() which is basically the same thing as select().
事實上。在send()後還有更多隱情，妳會注意有一個“集線器”，是一個名字是eventlet的事件循環。妳也可以看到一個trampoline()調用，作用是“使當前代碼休眠，直至socket可寫”。並且，在很後面的地方，我們仍然在一個poll（）調用中執行休眠，類似於在select（）中的實現。
To show the example of doing some “useful” work rather than sleeping all the time we run a busy loop greenthread:
爲展示可以做些“有用的”工作，而不是一直休眠，我們可以運行一個busy_loop的greenthread循環。
import eventlet
from eventlet.green import socket
def busy_loop():
while True:
i = 0
while i < 5000000:
i += 1
print "yielding"
eventlet.sleep()
eventlet.spawn(busy_loop)
sock = socket.socket()
sock.connect(('localhost', 1234))
sock.send('foo\n' * 10 * 1024 * 1024)Now every time the socket isn’t writable, we switch to the busy_loop() greenthread and do some work. Greenthreads must cooperatively yield to one another so we call eventlet.sleep() in busy_loop() to once again poll the socket to see if its writable. Again, if we use the ‘time’ command to run this:
每次當socket無法寫入，我們切換到名爲busy_loop()的greenthread，完成一些工作。Greenthreads必須通過yield迭代方式和其他進程合作，這樣我們可以在busy_loop()調用eventlet.sleep()一次再次 poll到socket檢測其是否可寫。接下來，如果我們使用‘time’命令再次運行這個示例：
$> time python ./test-eventlet-write.py yielding yielding yielding ... real 0m5.386s user 0m5.081s sys 0m0.088s
you can see we’re spending very little time sleeping.
妳就可以看到休眠花費了很少的時間。
(As an aside, I was going to take a look at gevent, but it doesn’t seem fundamentally different from eventlet. Am I wrong?)
Twisted
Long, long ago, in times of old, Nova switched from twisted to eventlet so it makes sense to take a quick look at twisted:
很久以前，舊石器時代，Nova switched from twisted to eventlet ，我們很有必要快速閱覽一下twisted：
from twisted.internet import protocol
from twisted.internet import reactor
class Test(protocol.Protocol):
def connectionMade(self):
self.transport.write('foo\n' * 2 * 1024 * 1024)
class TestClientFactory(protocol.ClientFactory):
def buildProtocol(self, addr):
return Test()
reactor.connectTCP('localhost', 1234, TestClientFactory())
reactor.run()What complicates the example most is twisted protocol abstraction which we need to use simply to write to the socket. The ‘reactor’ abstraction is simply twisted’s name for an event loop. So, we create a on-blocking socket, block in the event loop (using e.g. select()) until the connection completes and then
write to the socket. The transport.write() call will actually queue a writer in the reactor, return immediately and whenever the socket is writable, the writer will continue its work.
To show how you can run something in parallel, here’s how to run some code in a deferred callback:
def busy_loop(): i = 0 while i < 5000000: i += 1 reactor.callLater(0, busy_loop) reactor.connectTCP(...) reactor.callLater(0, busy_loop) reactor.run()
I’m using a timeout of zero here and it shows up a weakness in both twisted and eventlet – we want this busy_loop() code to only run when the socket isn’t writeable. In other words, we want the task to have a lower priority than the writer task. In both twisted and eventlet, the timed tasks are run before the
I/O tasks and there is no way to add a task which is only run if there are no runnable I/O tasks.
GLib
My introduction to async I/O was back when I was working on GNOME (beginning with GNOME’s CORBA ORB, called ORBit) so I can’t help comparing the above abstractions to GLib’s main loop. Here’s some equivalent code:
/* build with gcc -g -O0 -Wall $(pkg-config --libs --cflags glib-2.0) test-glib-write.c -o test-glib-write */
#include <errno.h>
#include <fcntl.h>
#include <stdio.h>
#include <string.h>
#include <unistd.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <glib.h>
GMainLoop *main_loop = NULL;
static gchar *strv[10 * 1024 * 1024];
static gchar *data = NULL;
int remaining = -1;
static gboolean
socket_writable(GIOChannel *source,
GIOCondition condition,
gpointer user_data)
{
int fd, sent;
fd = g_io_channel_unix_get_fd(source);
do
{
sent = write(fd, data, remaining);
if (sent == -1)
{
if (errno != EAGAIN)
{
fprintf(stderr, "Write error: %s\n", strerror(errno));
goto finished;
}
return TRUE;
}
data = &data[sent];
remaining -= sent;
}
while (sent > 0 && remaining > 0);
if (remaining <= 0)
goto finished;
return TRUE;
finished:
g_main_loop_quit(main_loop);
return FALSE;
}
static gboolean
busy_loop(gpointer data)
{
int i = 0;
while (i < 5000000)
i += 1;
return TRUE;
}
int
main(int argc, char **argv)
{
GIOChannel *io_channel;
guint io_watch;
int fd;
struct sockaddr_in addr;
int i;
gchar *to_free;
for (i = 0; i < G_N_ELEMENTS(strv)-1; i++)
strv[i] = "foo\n";
strv[G_N_ELEMENTS(strv)-1] = NULL;
data = to_free = g_strjoinv(NULL, strv);
remaining = strlen(data);
fd = socket(AF_INET, SOCK_STREAM, 0);
memset(&addr, 0, sizeof(struct sockaddr_in));
addr.sin_family = AF_INET;
addr.sin_port = htons(1234);
addr.sin_addr.s_addr = htonl(INADDR_LOOPBACK);
if (connect(fd, (struct sockaddr *)&addr, sizeof(addr)) == -1)
{
fprintf(stderr, "Error connecting to server: %s\n", strerror(errno));
return 1;
}
fcntl(fd, F_SETFL, O_NONBLOCK);
io_channel = g_io_channel_unix_new(fd);
io_watch = g_io_add_watch(io_channel,
G_IO_OUT,
(GIOFunc)socket_writable,
GINT_TO_POINTER(fd));
g_idle_add(busy_loop, NULL);
main_loop = g_main_loop_new(NULL, FALSE);
g_main_loop_run(main_loop);
g_main_loop_unref(main_loop);
g_source_remove(io_watch);
g_io_channel_unref(io_channel);
close(fd);
g_free(to_free);
return 0;
}Here I create a non-blocking socket, set up an ‘I/O watch’ to tell me when the socket is writable and, when it is, I keep blasting data into the socket until I get an EAGAIN. This is the point at which write() would block if it was a blocking socket and I return TRUE from the callback to say “call me again when the socket is writable”. Only when I’ve finished writing all of the data do I return FALSE and quit the main loop causing the g_main_loop_run() call to return.
The point about task priorities is illustrated nicely here. GLib does have the concept of priorities and has a “idle callback” facility you can use to run some code when no higher priority task is waiting to run. In this case, the busy_loop() function will *only* run when the socket is not writable.
Tulip
There’s a lot of talk lately about Guido’s Asynchronous IO Support Rebooted (PEP3156) efforts so, of course, we’ve got to have a look at that.
One interesting aspect of this effort is that it aims to support both the coroutine and callbacks style programming models. We’ll try out both models below.
Tulip, of course, has an event loop, time-based callbacks, I/O callbacks and I/O helper functions. We can build a simple variant of our non-blocking I/O example above using tulip’s event loop and I/O callback:
import errno
import select
import socket
import tulip
sock = socket.socket()
sock.connect(('localhost', 1234))
sock.setblocking(0)
buf = memoryview(str.encode('foo\n' * 2 * 1024 * 1024))
def do_write():
global buf
while True:
try:
buf = buf[sock.send(buf):]
except socket.error as e:
if e.errno != errno.EAGAIN:
raise e
return
def busy_loop():
i = 0
while i < 5000000:
i += 1
event_loop.call_soon(busy_loop)
event_loop = tulip.get_event_loop()
event_loop.add_writer(sock, do_write)
event_loop.call_soon(busy_loop)
event_loop.run_forever()We can go a step further and use tulip’s Protocol abstraction and connection helper:
import errno import select import socket import tulip class Protocol(tulip.Protocol): buf = b'foo\n' * 10 * 1024 * 1024 def connection_made(self, transport): event_loop.call_soon(busy_loop) transport.write(self.buf) transport.close() def connection_lost(self, exc): event_loop.stop() def busy_loop(): i = 0 while i < 5000000: i += 1 event_loop.call_soon(busy_loop) event_loop = tulip.get_event_loop() tulip.Task(event_loop.create_connection(Protocol, 'localhost', 1234)) event_loop.run_forever()
This is pretty similar to the twisted example and shows up yet another example of the lack of task prioritization being an issue. If we added the busy loop to the event loop before the connection completed, the scheduler would run the busy loop every time the connection task yields.
Coroutines, Generators and Subgenerators
Under the hood, tulip depends heavily on generators to implement coroutines. It’s worth digging into that concept a bit to understand what’s going on.
Firstly, remind yourself how a generator works:
def gen():
i = 0
while i < 2:
print(i)
yield
i += 1
i = gen()
print("yo!")
next(i)
print("hello!")
next(i)
print("bye!")
try:
next(i)
except StopIteration:
print("stopped")This will print:
yo! 0 hello! 1 bye! stopped
Now imagine a generator function which writes to a non-blocking socket and calls yield every time the write would block. You have the beginnings of coroutine based async I/O. To flesh out the idea, here’s our familiar example with some generator based infrastructure around it:
import collections
import errno
import select
import socket
sock = socket.socket()
sock.connect(('localhost', 1234))
sock.setblocking(0)
def busy_loop():
while True:
i = 0
while i < 5000000:
i += 1
yield
def write():
buf = memoryview(b'foo\n' * 2 * 1024 * 1024)
while len(buf):
try:
buf = buf[sock.send(buf):]
except socket.error as e:
if e.errno != errno.EAGAIN:
raise e
yield
quit()
Task = collections.namedtuple('Task', ['generator', 'wfd', 'idle'])
tasks = [
Task(busy_loop(), wfd=None, idle=True),
Task(write(), wfd=sock, idle=False)
]
running = True
def quit():
global running
running = False
while running:
finished = []
for n, t in enumerate(tasks):
try:
next(t.generator)
except StopIteration:
finished.append(n)
map(tasks.pop, finished)
wfds = [t.wfd for t in tasks if t.wfd]
timeout = 0 if [t for t in tasks if t.idle] else None
select.select([], wfds, [], timeout)You can see how the generator-based write() and busy_loop() coroutines are cooperatively yielding to one another just like greenthreads in eventlet would do. But, there’s a pretty fundamental flaw here – if we wanted to refactor the code above to re-use that write() method to e.g. call it multiple times with
different input, we’d need to do something like:
def write_stuff(): for i in write(b'foo' * 10 * 1024 * 1024): yield for i in write(b'bar' * 10 * 1024 * 1024): yield
but that’s pretty darn nasty! Well, that’s the whole idea behindSyntax for Delegating to a Subgenerator (PEP380). Since python 3.3, a generator can now yield to another generator using the ‘yield from’ syntax. This allows us to do:
...
def write(data):
buf = memoryview(data)
while len(buf):
try:
buf = buf[sock.send(buf):]
except socket.error as e:
if e.errno != errno.EAGAIN:
raise e
yield
def write_stuff():
yield from write(b'foo\n' * 2 * 1024 * 1024)
yield from write(b'bar\n' * 2 * 1024 * 1024)
quit()
Task = collections.namedtuple('Task', ['generator', 'wfd', 'idle'])
tasks = [
Task(busy_loop(), wfd=None, idle=True),
Task(write_stuff(), wfd=sock, idle=False)
]
...Conclusions?
Yeah, this is the point where I’ve figured out what we should do in OpenStack. Or not.
I really like the explicit nature of Tulip’s model – for each async task, you explicitly decide whether to block the current coroutine on its completion (or put another way, yield to another coroutine until the task has completed) or you register a callback to be notified of the tasks completion. I’d much prefer this to rather cavalier “don’t worry your little head” approach of hiding the async nature of what’s going on.
However, the prospect of porting something like Nova to this model is more than a little dauting. If you think about the call stack of an REST API request being handled and ultimately doing an rpc.cast() and that the entire call stack would need to be ported to ‘yield from’ in order for us to yield and handle another API request while waiting for the result of rpc.cast() …. as I said, daunting.
What I’m most interested in is how to design our new messaging APIto be able to support any and all of these models in future. I haven’t quite figured that out either, but it feels pretty doable.