[Libguestfs] [PATCH 0/5] Add support for thread-safe handle.

[Richard W.M. Jones]

This patch isn't ready to go upstream.  In fact, I think we might do a
quick 1.30 release soon, and save this patch, and also the extensive
changes proposed for the test suite[1], to after 1.30.

Currently it is not safe to use the same handle from multiple threads,
unless you implement your own mutexes.  See:
http://libguestfs.org/guestfs.3.html#multiple-handles-and-multiple-threads

These patches add support for a thread-safe handle, so you can use the
same handle concurrently from multiple threads without requiring the
caller to perform any special locking.

The implementation is fairly straightforward: a recursive lock is
added to the handle (using the gnulib gl_recursive_lock so it should
be fairly portable beyond POSIX threads).  The recursive lock is
required because libguestfs extensively calls itself.  Also a
recursive lock allows callbacks back to program code to work -- we
don't want to release the lock before a callback since that would
allow other threads to enter libguestfs using the same handle.

I studied the libvirt implementation which doesn't use a recursive
lock, but does use conditions to achieve the same thing more
efficiently.  It is considerably more complex.

The difficult part of the implementation is error handling (see
description of patch 3/5).  This patch causes an API change, which is
one reason why it cannot go upstream at the moment.

The tests pass, but apart from running the tests standalone and under
valgrind, and adding a (not very satisfactory) new test, I have not
tested the patches any further.

Comments welcome,

Rich.

[1] https://www.redhat.com/archives/libguestfs/2014-October/msg00208.html