On Thu, Mar 16, 2017 at 06:24:46PM +0100, Wojtek Porczyk wrote: > 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. Ok, well just go ahead & submit a suitable patch for libvirt-python and we'll take the discussion forward from there. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://entangle-photo.org -o- http://search.cpan.org/~danberr/ :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
