[libvirt] PATCH: Ensure errors are guarenteed reported in virConnectOpen

[Daniel Veillard]

On Thu, Aug 21, 2008 at 09:41:12AM +0100, Daniel P. Berrange wrote:
> On Thu, Aug 21, 2008 at 08:35:25AM +0200, Daniel Veillard wrote:
> > > To make it thread-safe we'll need to add a real virGetThreadLastError()
> > > API, which is something on my todo list - with that new apps can just
> > > call thevirGetThreadLastError() exclusively and never need to know the
> > > distinction between  global/connection errors which causes so much
> > > trouble. I'm fairly sure I can preseve existing semantics at same 
> > > time with some suitable internal cleverness.
> > 
> >   I really wished we could avoid thread local storage mess, and in
> > general anything having to do with API exported global variables. In
> > general (I mean for the vast majority of the userland code dealing with
> > libvirt) there is always a domain or connection object where we can plug
> > the error, and provide it in-context. The only exception is the
> > connection creation, maybe this means we need to provide a better entry
> > point for this, but I would really prefer to not expose the notion of
> > thread at the API level.
> 
> Well you see I want to be able to use the same virConnectPtr object
> from multiple threads. I've looked at how todo this and it actually
> won't be very hard once we have a way to report thread-local errors.

  not very hard ??? You expect to put a global lock in the connection
The threading problem is a pandora box, once you provide the
functionality people will use it in ways you didn't expect. You will see
things like people closing the connection in one thread while another
thread is still using it. I don't think you can catch all scenarios
so i'm quite worried about suggesting it will be usable and then facing
undebuggable scenarios coming from lost users.

> Re-using a single virConnectPtr object is important because when talking
> to a remote libvirtd instance, you don't want to have to open multiple
> connections for each thread in your app, because that will require the
> user to re-authenticate multiple times (or for the app to store your
> credentials - not cool)

  you keep one thread per connection. You will have to lock anyway,
it's not like you will gain anything by trying to parallelize on a
single connection. I really don't see what you're trying to do. Even
entry points without side effect will need some kind of locking.

Daniel

-- 
Red Hat Virtualization group http://redhat.com/virtualization/
Daniel Veillard      | virtualization library  http://libvirt.org/
veillard at redhat.com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine  http://rpmfind.net/