<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Tue, Dec 1, 2015 at 7:43 AM Tim Penhey <<a href="mailto:tim.penhey@canonical.com">tim.penhey@canonical.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi folks,<br>
<br>
The fslock was a mistake that I added to the codebase some time back. It<br>
provided an overly simplistic solution to a more complex problem.<br>
<br>
Really the filesystem shouldn't be used as a locking mechanism.<br>
<br>
Most of the code that exists for the fslock now is working around its<br>
deficiencies. Instead we should be looking for a better replacement.<br>
<br>
Some "features" that were added to fslock were added to work around the<br>
issue that the lock did not die with the process that created it, so<br>
some mechanism was needed to determine whether the lock should be broken<br>
or not.<br>
<br>
What we really need is a good OS agnostic abstraction that provides the<br>
ability to create a "named" lock, acquire the lock, release the lock,<br>
and make sure that the lock dies when the process dies, so another<br>
process that is waiting can acquire the lock. This way no "BreakLock"<br>
functionality is required, nor do we need to try and do think like<br>
remember which process owns the lock.<br>
<br>
So...<br>
<br>
We have three current operating systems we need to support:<br>
<br>
Linux - Ubuntu and CentOS<br>
MacOS - client only - bit the CLI uses a lock for the local cache<br>
Windows<br>
<br>
For Linux, and possibly MacOS, flock is a possibility, but can we do<br>
better? Is there something that is better suited?<br>
<br>
For Windows, while you can create global semaphores or mutex instances,<br>
I'm not sure of entities that die with the process. Can people recommend<br>
solutions?<br></blockquote><div><br></div><div>I've been wanting to do this for a long time (I think I've whinged in your vicinity about it before), but I've held off because of uncertainty about compatibility with NFS (which is probably a rare scenario, and only for the client).</div><div><br></div><div>I think it was jam that brought up the heritage of directory locking in bzr, where flock doesn't work reliably over NFS. I think that's old news though. The manpage for flock discusses the NFS/kernel limitations of flock; since we don't go back past precise, we should be fine.</div><div><br></div><div>I think flock (fcntl F_SETLK/F_GETLK) is an appropriate option for Linux and OS X. Windows has FileLock (<a href="https://msdn.microsoft.com/en-us/library/windows/desktop/aa365202(v=vs.85).aspx">https://msdn.microsoft.com/en-us/library/windows/desktop/aa365202(v=vs.85).aspx</a>), and LockFileEx (for more control). Just as with F_SETLK, if the process dies, the lock is released.</div><div><br></div><div>Cheers,</div><div>Andrew</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Cheers,<br>
Tim<br>
<br>
--<br>
Juju-dev mailing list<br>
<a href="mailto:Juju-dev@lists.ubuntu.com" target="_blank">Juju-dev@lists.ubuntu.com</a><br>
Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/juju-dev" rel="noreferrer" target="_blank">https://lists.ubuntu.com/mailman/listinfo/juju-dev</a><br>
</blockquote></div></div>