Re: [Libguestfs] [PATCH] library: per-handle locking support
On 05/29/2014 01:04 PM, Richard W.M. Jones wrote:
On Thu, May 29, 2014 at 12:21:39PM +0200, Maros Zatko wrote:
> Introduces private pool of muteces (per_handle_locks) guarded by read-write
> mutex (locks_lock) using guestfs__per_handle_lock_lock(g) and
> guestfs__per_handle_lock_unlock(g), where g is current valid guestfs_h handle.
> Above two are used in generator/c.ml at begin and end of each non-deamon call.
>
> New lock can be created using guestfs__per_handle_lock_add(g) and
> destroyed with guestfs__per_handle_lock_remove(g). These two are called
> automatically too. First one is called by guestfs_create and second by
> guestfs_destroy.
I'm a bit confused about why there is a pool of locks. Why not keep
the lock struct in the handle (guestfs_h)?
Yes, why not (obviously).
Rich.
First I've put recursive mutex into handle. This worked.
Next, due to previous discussion about this recursive manner, I've tried
it with ordinary ones.
This doesn't work. make check hangs on tests/qemu, other tests try to
double acquire lock and hangs,
same goes with guestfish. I found interesting that you can run
guestfish, add a disk but you can't launch it.
Unless you set LIBGUESTFS_DEBUG or TRACE flag then it hangs immediately :)
Do we want to have it recursive or investigate more for exact races and
have fine grained locking?
Ideas?
Patches will follow.
- maros