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