On Thu, Aug 02, 2012 at 05:20:52PM +0100, Daniel P. Berrange wrote:
> From: "Daniel P. Berrange" <berrange@xxxxxxxxxx>
>
> The previously introduced virFile{Lock,Unlock} APIs provide a
> way to acquire/release fcntl() locks on individual files. For
> unknown reason though, the POSIX spec says that fcntl() locks
> are released when *any* file handle refering to the same path
> is closed. In the following sequence
>
> threadA: fd1 = open("foo")
> threadB: fd2 = open("foo")
> threadA: virFileLock(fd1)
> threadB: virFileLock(fd2)
> threadB: close(fd2)
>
> you'd expect threadA to come out holding a lock on 'foo', and
> indeed it does hold a lock for a very short time. Unfortunately
> when threadB does close(fd2) this releases the lock associated
> with fd1. For the current libvirt use case for virFileLock -
> pidfiles - this doesn't matter since the lock is acquired
> at startup while single threaded an never released until
> exit.
>
> To provide a more generally useful API though, it is neccessary
> to introduce a slightly higher level abstraction, which is to
> be referred to as a "lockspace". This is to be provided by
> a virLockSpacePtr object in src/util/virlockspace.{c,h}. The
> core idea is that the lockspace keeps track of what files are
> already open+locked. This means that when a 2nd thread comes
> along and tries to acquire a lock, it doesn't end up opening
> and closing a new FD. The lockspace just checks the current
> list of held locks and immediately returns VIR_ERR_RESOURCE_BUSY.
>
> NB, the API as it stands is designed on the basis that the
> files being locked are not being otherwise opened and used
> by the application code. ie the files which are used to
> maintain the locks are not the files associated with the
> resources themselves. One approach to using this API is to
> acquire locks based on a hash of the filepath.
>
> eg to lock /var/lib/libvirt/images/foo.img the application
> might do
>
> virLockSpacePtr lockspace = virLockSpaceNew("/var/lib/libvirt/imagelocks");
> lockname = md5sum("/var/lib/libvirt/images/foo.img")
> virLockSpaceAcquireLock(lockspace, lockname)
>
> This patch is the basis for the soon to be re-submitted
> patch series providing a virtlockd daemon
Sorry, ignore this patch. I forgot to commit some other
local changes to it before sending. See the new v2.
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list