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 :| _______________________________________________ Devel mailing list -- devel@xxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxx
