Re: [libvirt] libvirtaio: libvirt-python asyncio event impl

On Thu, Mar 16, 2017 at 04:38:23PM +0000, Daniel P. Berrange wrote: > On Thu, Mar 16, 2017 at 05:30:40PM +0100, Wojtek Porczyk wrote: > > Hello, libvirt-list, > > > > I wrote an event implementation wrapping an asyncio event loop [1]. > > I would like to contribute it back to libvirt-python, to be offered > > alongside the Default Impl in C. > > > > [1] https://github.com/woju/libvirtaio > > > > Also it contains a workaround for a memory leak around the custom loop > > implementation: > > https://github.com/woju/libvirtaio/blob/8685cfc/libvirtaio.py#L66-L92 > > > > How should I submit this? As a patch against libvirt-python.git, appending to > > libvirt-override.py? > > IIUC, the asyncio module you're using is new in python 3.4 ? The libvirt > python code aims to be compatible with python >= 2.6 at this time, so > there's a mis-match there. > > So if we did include that in the main libvirt python module, we'd have > to figure out a suitable approach to avoid trying to import the > non-existant module when people do "import libvirt". That's right, asyncio (and this module) is compatible with 3.3 (mainly because of "yield from" syntax) and included in standard library from 3.4. We can ship it as separate module (like libvirt vs libvirtmod) and do something like this at the beginning on libvirt-override.py: try: from libvirtaio import LibvirtAsyncIOEventImpl # assuming it won't get renamed in review __all__ += ['LibvirtAsyncIOEventImpl'] except (ImportError, SyntaxError): pass (Just tested on 2.7). People will probably import this unconditionally, since they know, what event loop they want to run. In case of doubt, they always can: import libvirt try: libvirt.LibvirtAsyncIOEventImpl().register() except AttributeError: libvirt.virEventRegisterDefaultImpl() def event_loop(): while True: libvirt.virEventRunDefaultImpl() # ... import threading threading.Thread(target=event_loop).start() execute_ff_callback() can be merged regardless, since it is probably compatible with 2.5 (that's when ctypes arrived). > Or we could just leave it as a standalone python module and document its > existence on our python binding page (http://libvirt.org/python.html) I'd be glad if you merged this module, since 1) it would be more accessible, 2) won't break between releases (currently it is in danger because of the opaque object handling). Since we would be (at least now) the only user of this, I volunteer as tester/patch submitter against this part of code.