On Wed, Dec 13, 2023 at 11:04:54AM +0000, John Levon wrote:
These two functions are currently private to libvirt, hence not available to
consumers. Would it be possible to make them public? Without them, there's no
way to do any libvirt call without stomping on an existing error that you may
want to preserve.
I have multiple threads sharing a remote connection (to local libvirtd). I need
to be able to handle connection drops (e.g. libvirtd restart). Long story short,
the only approach I've found that actually works properly is that there's one
main conn object, each thread has a virConnectRef() to it, and whenever a thread
gets an error, we check in the error callback if !virConnectIsAlive(). If so, we
close the thread's conn, and potentially also clean up the main conn.
I wonder if we should take the position that this behaviour is a libvirt
bug.
We declare that on return from an API call, the last error object reflects
any error that occurred in this API call.
Libvirt is executing the error callback and work done in the error callback
is breaking our API guarantee.
This broken API guarantee is not the app's fault, it is libvirt's fault for
not protecting itself against things the callback might do.
IOW, should we fix the virDispatchError function, to do the save/restore
dance either side of invoking the callback. This would aviod exposing any
new APIs, and make the app should "just work".
With regards,
Daniel
--
|:
https://berrange.com -o-
https://www.flickr.com/photos/dberrange :|
|:
https://libvirt.org -o-
https://fstop138.berrange.com :|
|:
https://entangle-photo.org -o-
https://www.instagram.com/dberrange :|