Open Stack

On Feb 7, 2014, at 1:51 AM, Chris Behrens <cbehrens at codestud.com> wrote:

> 
> On Feb 6, 2014, at 11:07 PM, Joshua Harlow <harlowja at yahoo-inc.com> wrote:
> 
>> +1
>> 
>> To give an example as to why eventlet implicit monkey patch the world isn't especially great (although it's what we are currently using throughout openstack).
>> 
>> The way I think about how it works is to think about what libraries that a single piece of code calls and how it is very hard to predict whether that code will trigger a implicit switch (conceptually similar to a context switch).
> 
> Conversely, switching to asyncio means that every single module call that would have blocked before monkey patching… will now block. What is worse? :)
> 

Are we perhaps thinking about this in the wrong way?

As I’m looking at the services that make heavy use of eventlet/etc - many of them (to me) would benefit more from the typical task queue pattern most SOA systems use. At that point your producers + consumers would use a common abstracted back end - a simple:

class Reader(object):
     def put():
     def get():

abstraction means that the Reader class could extend from - or be extended - to encompass the various models out there - local threads + queue.Queue, asyncIO, eventlet / etc. This means that you force everyone into a message passing/"shared nothing” architecture where even on a deployment level, a given individual could swap in say, twisted, or tornado, or…

It seems that baking concurrency models into the individual clients / services adds some opinionated choices that may not scale, or fit the needs of a large-scale deployment. This is one of the things looking at the client tools I’ve noticed - don’t dictate a concurrency backend, treat it as producer/consumer/message passing and you end up with something that can potentially scale out a lot more. 

jesse