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

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


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