[openstack-dev] Reasoning behind my vote on the Go topic

Chris Friesen chris.friesen at windriver.com
Thu Jun 9 03:05:37 UTC 2016

On 06/07/2016 04:26 PM, Ben Meyer wrote:
> On 06/07/2016 06:09 PM, Samuel Merritt wrote:
>> On 6/7/16 12:00 PM, Monty Taylor wrote:
>>> [snip]
>>> I'd rather see us focus energy on Python3, asyncio and its pluggable
>>> event loops. The work in:
>>> http://magic.io/blog/uvloop-blazing-fast-python-networking/
>>> is a great indication in an actual apples-to-apples comparison of what
>>> can be accomplished in python doing IO-bound activities by using modern
>>> Python techniques. I think that comparing python2+eventlet to a fresh
>>> rewrite in Go isn't 100% of the story. A TON of work has gone in to
>>> Python that we're not taking advantage of because we're still supporting
>>> Python2. So what I've love to see in the realm of comparative
>>> experimentation is to see if the existing Python we already have can be
>>> leveraged as we adopt newer and more modern things.
>> Asyncio, eventlet, and other similar libraries are all very good for
>> performing asynchronous IO on sockets and pipes. However, none of them
>> help for filesystem IO. That's why Swift needs a golang object server:
>> the go runtime will keep some goroutines running even though some
>> other goroutines are performing filesystem IO, whereas filesystem IO
>> in Python blocks the entire process, asyncio or no asyncio.
> That can be modified. gevent has a tool
> (http://www.gevent.org/gevent.fileobject.html) that enables the File IO
> to be async  as well by putting the file into non-blocking mode. I've
> used it, and it works and scales well.

Arguably non-blocking isn't really async when it comes to reads.  I suspect what 
we really want is full-async where you issue a request and then get notified 
when it's done.


More information about the OpenStack-dev mailing list