On 10/10/2012 09:32 AM, Matthias Bolte wrote:
2012/10/10 Daniel P. Berrange <berrange(a)redhat.com>:
> From: "Daniel P. Berrange" <berrange(a)redhat.com>
>
> 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(a)redhat.com>
> ---
> 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?
Those calls are safe from the perspective of libvirt using them, but you
are correct that if libvirt is linked in to an application that is also
directly using those libraries, that the init functions can then be
called multiple times, at which point you are better off manually
calling virInitialize before spawning other threads.
> + * The only time it would be neccessary to call virInitialize is
if the
s/neccessary/necessary/
> + * application did not invoke virConnectOpen as its first API
call.
> + *
> + * Returns 0 in case of success, -1 in case of error
> + */
--
Eric Blake eblake(a)redhat.com +1-919-301-3266
Libvirt virtualization library
http://libvirt.org