utils/fslock needs to DIAF

[Andrew Wilkins]

On Tue, Dec 1, 2015 at 7:58 AM David Cheney <david.cheney at canonical.com>
wrote:

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

I don't have a problem with that, but I'd like to know why it's better.


>
> 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
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20151201/54c3a178/attachment-0001.html>