Re: Public virErrorPreserveLast()/virErrorRestore()
On Thu, Dec 14, 2023 at 05:55:41PM +0100, Peter Krempa wrote:
On Thu, Dec 14, 2023 at 12:03:55 +0000, John Levon wrote:
Using the global error handler function is not a very good idea in
multithreaded applications, so I'd really suggest to have a generic
handler function that you'll call after receiving a failure code from
any of the libvirt APIs you care about and that will preserve/raise the
error in your application.
Right, both virConnSetErrorFunc & virSetErrorFunc are functions
from day 1, that we effectively considered to be redundant once
we retrofitted thread local error reporting into libvirt in the
distant past. Pretty much every all just calls virSetErrorFunc
to disable the silly built-in default print-to-stderr behaviour
we unfortunately have.
Additionally for handling disconnects libvirt provides a connection
close callback registrable via virConnectRegisterCloseCallback(), which
can be registered multiple times with private data for each instance.
That might help you getting rid of the generic error handler's duty to
catch disconnects.
OpenStack uses this callback to trigger reconnect when a connection
dies, and I'd consider that good practice. It also executes in clean
stack context direct from the event loop, as opposed to the error
callbacks which can be triggered from completely arbitrary application
code stack context.
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 :|