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.
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
