On Mon, May 09, 2011 at 10:32:10AM +0100, Daniel P. Berrange wrote: > On Fri, May 06, 2011 at 05:43:41PM +0100, Richard W.M. Jones wrote: > > > > I can set the global error handling function (virSetErrorFunc). That > > doesn't seem to be a good idea from a library. Looking at the code, > > it doesn't appear that the internal virErrorHandler is thread-local, > > so I can't set it and restore it around the function call. > > > > I can set the error handling function _after_ I've got a connection > > object (virConnSetErrorFunc). That doesn't help with making the > > initial connection. > > > > libguestfs itself has the same problem with the guestfs_create call, > > so I'm not going to point any fingers :-) However it seems like a > > shortcoming of the libvirt API. > > > > Am I missing something here? > > Not really. I really consider the default error printing function > itself to be a flawed idea as a library shouldn't print to stderr > by default. I'm really torn on whether we can change it though, > since although most apps disable it, some may be relying on it. > > Perhaps adding a flag to virConnectOpenAuth(), VIR_CONNECT_NOP_ERROR_FUNC > but not sure how practical that is to actually implement in our internal > error handling infrastructure. Is there a way to add / make the default error function be thread local? As long as I can null it out around the call safely (without affecting other threads) then that fixes it for me. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://et.redhat.com/~rjones/virt-df/ -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list