On Wed, Oct 10, 2012 at 05:32:21PM +0200, Matthias Bolte wrote: > 2012/10/10 Daniel P. Berrange <berrange@xxxxxxxxxx>: > > From: "Daniel P. Berrange" <berrange@xxxxxxxxxx> > > > > Currently there is a restriction that multi-threaded applications > > must manually call virInitialize, before threads start using > > libvirt, because it is not thread-safe. By switching it to use > > a virOnceControl initializer we gain thread safety, and thus > > applications no longer need to manually call it. They can rely > > on virConnectOpen invoking it for them. > > > > Signed-off-by: Daniel P. Berrange <berrange@xxxxxxxxxx> > > --- > > src/libvirt.c | 139 ++++++++++++++++++++++++++++++---------------------------- > > 1 file changed, 71 insertions(+), 68 deletions(-) > > > +/** > > + * virInitialize: > > + * > > + * Initialize the library. > > + * > > + * This method is invoked automatically by any of the virConnectOpen API > > + * calls. Since release 1.0.0, there is no need to call this method even > > + * in a multithreaded application, since initialization is performed in > > + * a thread safe manner. > > Are you really sure that this is true? What about the calls > gcry_control and curl_global_init? There's no issue with that. We are still ensuring that virInitialize is the first thing invoked in libvirt. We are simply doing that automatically now, instead of requiring client apps todo it. > > > + * The only time it would be neccessary to call virInitialize is if the > > + * application did not invoke virConnectOpen as its first API call. > > + * > > + * Returns 0 in case of success, -1 in case of error > > + */ Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list