On Fri, May 16, 2014 at 11:47:17AM -0400, Daniel P. Berrange wrote: > On Fri, May 16, 2014 at 04:44:41PM +0100, Richard W.M. Jones wrote: > > On Thu, May 15, 2014 at 05:39:08PM +0200, [email protected] wrote: > > > + > > > + pr "gl_recursive_lock_define_initialized(static, global_lock)\n"; > > > > static? > > > > I suspect this only allows one libguestfs handle per process into the > > critical section at once. I think the lock needs to be per-handle > > unless I'm misunderstanding what this is for. > > Agreed, any locking should be per-handle, and I wouldn't expect to need > to use recursive mutexes either. Internal libguestfs code shouldn't be > calling back out to the public libguestfs API surely, so shouldn't need > to have re-entrancy
Actually libguestfs does call itself quite a lot. Whether it should call itself through the public API or not is another matter -- we could change that fairly easily. Is there a problem with recursive mutexes? Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into KVM guests. http://libguestfs.org/virt-v2v _______________________________________________ Libguestfs mailing list [email protected] https://www.redhat.com/mailman/listinfo/libguestfs
