utils/fslock needs to DIAF
Andrew Wilkins
andrew.wilkins at canonical.com
Tue Dec 1 00:00:44 UTC 2015
On Tue, Dec 1, 2015 at 7:57 AM David Cheney <david.cheney at canonical.com>
wrote:
> Doesn't look like there is windows support, and it uses fcntl (flock)
> under the hood, which is what we have now.
>
flock isn't the problematic thing Tim is talking about. utils/fslock
attempts to create a directory in a known location, and if it succeeds, it
"holds the lock". Unlocking means removing the directory.
We would have to contribute Windows support, but it's not hard, I've done
it before.
> On Tue, Dec 1, 2015 at 10:55 AM, Casey Marshall
> <casey.marshall at canonical.com> wrote:
> > How about github.com/camlistore/lock ?
> >
> > On Mon, Nov 30, 2015 at 5:43 PM, 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?
> >>
> >> 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
> >
>
> --
> 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/03264305/attachment.html>
More information about the Juju-dev
mailing list