summaryrefslogtreecommitdiff
path: root/libvirtaio.py
Commit message (Collapse)AuthorAgeFilesLines
* libvirtaio: add better docs on best practice usage patternDaniel P. Berrangé2022-06-081-2/+21
| | | | Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
* libvirtio: lazy create the Event object in drain()Daniel P. Berrangé2022-06-081-5/+11
| | | | | | | | | | | | | | | | | | | | | The drain method uses an asyncio.Event object to be notified when other coroutines have removed all registered callbacks. The Event object needs to be associated with the coroutine that the event loop is running with and currently this is achieved by passing in the 'loop' parameter. Unfortunately Python 3.10 has removed the 'loop' parameter and now the object is associated implicitly with the current thread's event loop. At the time the virEventAsyncIOImpl constructor is called, however, there is no guarantee that an event loop has been set for the thread. The explicitly passed in 'loop' parameter would handle this scenario. For portability with Python >= 3.10 we need to delay creation of the Event object until we have a guarantee that there is a loop associated with the current thread. This is achieved by lazily creating the Event object inside the 'drain' method, which is expected to be invoked from coroutine context and thus ensure a loop is associated. Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
* libvirtaio: convert to using 'async' / 'await' syntaxChris Gunn2022-06-081-9/+6
| | | | | | | | | | | | | The 'async' keyword is new in Python 3.5, as a way to declare that a method is a coroutine. This replaces the '@asyncio.coroutine' decorator that is deprecated since 3.8 and scheduled to be removed in 3.11 The 'await' keyword has to be used instead of 'yield' from any coroutines declared with 'async'. Signed-off-by: Chris Gunn <chrisgun@microsoft.com> [DB: Split off from a larger patch mixing multiple changes] Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
* libvirtaio: drop back compat for python < 3.4.4Chris Gunn2022-06-081-11/+3
| | | | | | | | | | setup.py ensures we have python >= 3.5, so there is no need to do back compat with the 'asyncio.ensure_future' method, which was new in 3.4.4 Signed-off-by: Chris Gunn <chrisgun@microsoft.com> [DB: Split off from a larger patch mixing multiple changes] Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
* Revert "libvirtaio: Drop object(*args, **kwargs)"v6.7.0Philipp Hahn2020-08-281-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit f4be03b330125ab1e5a2bb10b4f12674aeff4691. While object.__init__() does not expect any additional arguments, this construct is required for Pythons multiple inheritance implementation. The original author Wojtek Porczyk <woju@invisiblethingslab.com> explained is this way: > I'm sorry I didn't notice this earlier, but the commit f4be03b3 dated > 2020-04-20 [0] is wrong. The super().__init__(*args, **kwargs) in > Callback.__init__ was there on purpose, because of how Python's inheritance in > new-style classes works. > > Let me explain this a bit, because it is not obvious. > > Suppose you had diamond inheritance like this: > > class A(object): pass > class B(A): pass > class C(A): pass > class D(B,C): pass > > And those classes needed a common function with varying arguments: > > class A(object): > def spam(self, a): print(f'A: {a}') > class B(A): > def spam(self, b): print(f'B: {b}') > class C(A): > def spam(self, c): print(f'C: {c}') > class D(B,C): > def spam(self, d): print(f'D: {d}') > > The way to call all parent's functions exactly once (as per MRO) and accept > all arguments and also forbid unknown arguments is to accept **kwargs > everywhere and pass them to super().spam(): > > class A: > def spam(self, a): > print(f'A: {a}') > class B(A): > def spam(self, b, **kwargs): > print(f'B: {b}') > super().spam(**kwargs) > class C(A): > def spam(self, c, **kwargs): > print(f'C: {c}') > super().spam(**kwargs) > class D(B, C): > def spam(self, d, **kwargs): > print(f'D: {d}') > super().spam(**kwargs) > > Let's run this: > > >>> B().spam(a=1, b=2) > B: 2 > A: 1 > >>> D().spam(a=1, b=2, c=3, d=4) > D: 4 > B: 2 > C: 3 > A: 1 > > You may notice that super() in B.spam refers to two different classes, either > A or C, depending on inheritance order in yet undefined classes (as of B's > definition). > > That's why the conclusion that super() in Callback.__init__ refers to object > is wrong. In this example, spam=__init__, A=object, B=Callback and C and D are > not yet written, but theoretically possible classes that could be written by > someone else. Why would they be needed, I don't know, but if someone writes > them, s/he would be out of options to invent new arguments to C.__init__. > > Note that super().__init__(*args, **kwargs) when super() refers to object > isn't harmful, and just ensures that args and kwargs are empty (i.e. no > unknown arguments were passed). In fact, this is exactly why object.__init__() > takes no arguments since Python 2.6 [1][2], as you correctly point out in the > commit message. > > I don't think this breaks anything (I very much doubt anyone would need to > write code that would trigger this), nevertheless, as the commit is both > pointless and wrong, and as the original author of libvirtaio I'd like to ask > for this commit to be reverted. If this breaks some static analysis tool, > could you just suppress it for this particular line? > > > [0] https://gitlab.com/libvirt/libvirt-python/-/commit/f4be03b330125ab1e5a2bb10b4f12674aeff4691 > [1] https://bugs.python.org/issue1683368 > [2] https://docs.python.org/3/whatsnew/2.6.html#porting-to-python-2-6 > (fourth point) > Signed-off-by: Philipp Hahn <hahn@univention.de>
* libvirtaio: Add manual PEP 484 type annotationsPhilipp Hahn2020-08-071-38/+41
| | | | Signed-off-by: Philipp Hahn <hahn@univention.de>
* libvirtaio: assert callback typePhilipp Hahn2020-08-061-2/+7
| | | | | | | self.callbacks contains a mix of FDCallback and TimeoutCallback, while the update code does not explicitly check for. Signed-off-by: Philipp Hahn <hahn@univention.de>
* libvirtaio: Fix return typePhilipp Hahn2020-08-061-2/+1
| | | | | | libvirtaio.py:364: error: "virEventInvokeFreeCallback" does not return a value Signed-off-by: Philipp Hahn <hahn@univention.de>
* libvirtaio: Drop object(*args, **kwargs)Philipp Hahn2020-08-061-2/+1
| | | | | | object.__init__() does not expect those parameters. Signed-off-by: Philipp Hahn <hahn@univention.de>
* libvirtaio: Cleanup importsPhilipp Hahn2020-08-061-7/+7
| | | | | | Move imports to top Signed-off-by: Philipp Hahn <hahn@univention.de>
* Normalize white spacePhilipp Hahn2020-08-061-7/+15
| | | | | | | indent by 4 spaces one spaces around assignments Signed-off-by: Philipp Hahn <hahn@univention.de>
* libvirtaio: Fix return types of callbackPhilipp Hahn2020-07-271-6/+12
| | | | | | | | | | | | | | libvirt defines the signature for the callback functions, e.g. the functions for remove() must return -1 on error and 0 on success. Raising an exception violates that contract. _remove_timeout() did not explicitly handle a double-remove and implicitly passed on the exception. update() expects no return value, so remove the pointless return to pass on None. Signed-off-by: Philipp Hahn <hahn@univention.de>
* libvirtaio: Fix compat with python 3.7Cole Robinson2018-06-271-4/+7
| | | | | | | | | | | | | | | In python 3.7, async is now a keyword, so this throws a syntax error: File "/usr/lib64/python3.7/site-packages/libvirtaio.py", line 49 from asyncio import async as ensure_future ^ SyntaxError: invalid syntax Switch to getattr trickery to accomplish the same goal Reviewed-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com> Signed-off-by: Cole Robinson <crobinso@redhat.com>
* libvirtaio: add .drain() coroutineWojtek Porczyk2017-09-261-2/+34
| | | | | | | | The intended use is to ensure that the implementation is empty, which is one way to ensure that all connections were properly closed and file descriptors reclaimed. Signed-off-by: Wojtek Porczyk <woju@invisiblethingslab.com>
* libvirtaio: keep track of the current implementationWojtek Porczyk2017-09-261-2/+14
| | | | | | | | Since 7534c19 it is not possible to register event implementation twice. Instead, allow for retrieving the current one, should it be needed afterwards. Signed-off-by: Wojtek Porczyk <woju@invisiblethingslab.com>
* libvirtaio: fix closing of the objectsWojtek Porczyk2017-09-261-6/+1
| | | | | | | | - Descriptor.close() was a dead code, never used. - TimeoutCallback.close(), as a cleanup function, should have called super() as last statement, not first Signed-off-by: Wojtek Porczyk <woju@invisiblethingslab.com>
* libvirtaio: do not double-add callbacksWojtek Porczyk2017-09-261-5/+4
| | | | | | | This was a harmless bug, without any impact, but it is wrong to manage the collection of callbacks from it's members. Signed-off-by: Wojtek Porczyk <woju@invisiblethingslab.com>
* libvirtaio: cache the list of callbacks when callingWojtek Porczyk2017-09-261-1/+1
| | | | | | | | | | | | | | | | | | | When the callback causes something that results in changes wrt registered handles, python aborts iteration. Relevant error message: Exception in callback None() handle: <Handle cancelled> Traceback (most recent call last): File "/usr/lib64/python3.5/asyncio/events.py", line 126, in _run self._callback(*self._args) File "/usr/lib64/python3.5/site-packages/libvirtaio.py", line 99, in _handle for callback in self.callbacks.values(): RuntimeError: dictionary changed size during iteration QubesOS/qubes-issues#2805 Signed-off-by: Wojtek Porczyk <woju@invisiblethingslab.com>
* libvirtaio: add more debug loggingWojtek Porczyk2017-09-261-8/+25
| | | | | | | This logging is helpful for tracing problems with unclosed connections and leaking file descriptors. Signed-off-by: Wojtek Porczyk <woju@invisiblethingslab.com>
* Add asyncio event loop implementationWojtek Porczyk2017-04-041-0/+399
This is usable only on python >= 3.4 (or 3.3 with out-of-tree asyncio), however it should be harmless for anyone with older python versions. In simplest case, to have the callbacks queued on the default loop: >>> import libvirtaio >>> libvirtaio.virEventRegisterAsyncIOImpl() The function is not present on non-compatible platforms. Signed-off-by: Wojtek Porczyk <woju@invisiblethingslab.com>
View Lorry Controller Status