[Libguestfs] [PATCH for discussion only 0/3] Implement mutexes to limit number of concurrent instances of libguestfs.

[Richard W.M. Jones]

These three patches (for discussion only, NOT to be applied) implement
a mutex system that lets the user limit the number of libguestfs
instances that can be launched per host.  There are two uses that I
have identified for this: firstly so we can enable parallel-tests (the
default in automake >= 1.13) without blowing up the host.  Secondly
oVirt has raised concerns about how to limit the number of libguestfs
appliances that can run to prevent this from interfering with their
ordinary guests.

The mutex is easy to use: You specify a POSIX semaphore file and the
maximum number of instances you want to allow to run at the same time,
eg:

 LIBGUESTFS_MUTEX_FILE=/guestfs.mutex
 LIBGUESTFS_MUTEX_LIMIT=3
 export LIBGUESTFS_MUTEX_FILE LIBGUESTFS_MUTEX_LIMIT

As long as each handle has the same settings, the limit is applied
transparently, with handles over the limit waiting for earlier ones to
finish.  (These can of course also be set through the API).  There is
also a way to have libguestfs choose a suitable limit for you, and the
system is entirely optional so that *not* setting these variables
results in no limits -- ie. the same as current behaviour.

Unfortunately this doesn't quite work because the design of POSIX
semaphores is a slightly braindead.  It's not possible to have the
semaphore be automatically recovered if the process crashes.  See:
http://stackoverflow.com/questions/2053679/how-do-i-recover-a-semaphore-when-the-process-that-decremented-it-to-zero-crashe
As a result when you try to run the tests you'll find that the
semaphore count slowly creeps up until the test suite stops running.

In any case, POSIX semaphores are annoying in other ways; for example
they don't live in the true filesystem, but in their own separate
namespace (exposed under /dev/shm).

To get around this I'll have to reimplement this using filesystem
locks.

Rich.