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

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