Open Stack

On 07/03/2014 04:27 PM, Mark McLoughlin wrote:
> Ceilometer's code is run in response to various I/O events like REST API
> requests, RPC calls, notifications received, etc. We eventually want the
> asyncio event loop to be what schedules Ceilometer's code in response to
> these events. Right now, it is eventlet doing that.
>
> Now, because we're using eventlet, the code that is run in response to
> these events looks like synchronous code that makes a bunch of
> synchronous calls. For example, the code might do some_sync_op() and
> that will cause a context switch to a different greenthread (within the
> same native thread) where we might handle another I/O event (like a REST
> API request) while we're waiting for some_sync_op() to return:
>
>    def foo(self):
>        result = some_sync_op()  # this may yield to another greenlet
>        return do_stuff(result)
>
> Eventlet's infamous monkey patching is what make this magic happen.
>
> When we switch to asyncio's event loop, all of this code needs to be
> ported to asyncio's explicitly asynchronous approach. We might do:
>
>    @asyncio.coroutine
>    def foo(self):
>        result = yield from some_async_op(...)
>        return do_stuff(result)
>
> or:
>
>    @asyncio.coroutine
>    def foo(self):
>        fut = Future()
>        some_async_op(callback=fut.set_result)
>        ...
>        result = yield from fut
>        return do_stuff(result)
>
> Porting from eventlet's implicit async approach to asyncio's explicit
> async API will be seriously time consuming and we need to be able to do
> it piece-by-piece.

Am I right in saying that this implies a change to the effective API for 
oslo.messaging[1]? I.e. every invocation on the library, e.g. a call or 
a cast, will need to be changed to be explicitly asynchronous?

[1] Not necessarily a change to the signature of functions, but a change 
to the manner in which they are invoked.