[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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



On Thu, Aug 21, 2008 at 08:35:25AM +0200, Daniel Veillard wrote:
> On Wed, Aug 20, 2008 at 07:24:59PM +0100, Daniel P. Berrange wrote:
> > On Wed, Aug 20, 2008 at 02:22:58PM +0100, Richard W.M. Jones wrote:
> > > On Tue, Aug 19, 2008 at 11:35:18AM +0100, Daniel P. Berrange wrote:
> > > > The guarenteed correct solution is actually rather simple
> > > > 
> > > >  - Always report errors against the virConnect object, even in the driver
> > > >    open method
> > > > 
> > > >  - In the cleanup patch of do_open() in libvirt.c, if no global error is
> > > >    set, copy the error from the virConnect object's virError, into the 
> > > >    global virError.
> > > 
> > > +1 , although unfortunately this isn't thread-safe.  Nothing can be
> > > thread-safe unless we change the API.
> > 
> > Well we're not making it any less thread-safe. You alrady have to use the
> > virGetLastError() global func - we're simply making sure it actually
> > records all errors. 
> > 
> > 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.

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)

Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]