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

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-w... 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.