utils/fslock needs to DIAF

[David Cheney]

Please no. The better way is to use an abstract unix domain socket to
create a mutex.

On Tue, Dec 1, 2015 at 10:56 AM, Andrew Wilkins
<andrew.wilkins at canonical.com> wrote:
> On Tue, Dec 1, 2015 at 7:43 AM Tim Penhey <tim.penhey at canonical.com> wrote:
>>
>> Hi folks,
>>
>> The fslock was a mistake that I added to the codebase some time back. It
>> provided an overly simplistic solution to a more complex problem.
>>
>> Really the filesystem shouldn't be used as a locking mechanism.
>>
>> Most of the code that exists for the fslock now is working around its
>> deficiencies. Instead we should be looking for a better replacement.
>>
>> Some "features" that were added to fslock were added to work around the
>> issue that the lock did not die with the process that created it, so
>> some mechanism was needed to determine whether the lock should be broken
>> or not.
>>
>> What we really need is a good OS agnostic abstraction that provides the
>> ability to create a "named" lock, acquire the lock, release the lock,
>> and make sure that the lock dies when the process dies, so another
>> process that is waiting can acquire the lock. This way no "BreakLock"
>> functionality is required, nor do we need to try and do think like
>> remember which process owns the lock.
>>
>> So...
>>
>> We have three current operating systems we need to support:
>>
>> Linux - Ubuntu and CentOS
>> MacOS - client only - bit the CLI uses a lock for the local cache
>> Windows
>>
>> For Linux, and possibly MacOS, flock is a possibility, but can we do
>> better? Is there something that is better suited?
>>
>> For Windows, while you can create global semaphores or mutex instances,
>> I'm not sure of entities that die with the process. Can people recommend
>> solutions?
>
>
> 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).
>
> 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.
>
> I think flock (fcntl F_SETLK/F_GETLK) is an appropriate option for Linux and
> OS X. Windows has FileLock
> (https://msdn.microsoft.com/en-us/library/windows/desktop/aa365202(v=vs.85).aspx),
> and LockFileEx (for more control). Just as with F_SETLK, if the process
> dies, the lock is released.
>
> Cheers,
> Andrew
>
>> Cheers,
>> Tim
>>
>> --
>> Juju-dev mailing list
>> Juju-dev at lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
>
> --
> Juju-dev mailing list
> Juju-dev at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>